数据库为什么不加外键，业务数据的依赖关系都在代码里实现。个人认为，这样做的好处是系统不强依赖数据库，数据库仅仅是数据的存储媒介，没有外键意味着数据库不是存储业务逻辑媒介。方便日后可能会发生的场景：
1. 需求升级，现有库表结构扩展
2. 数据迁移
3. 数据库升级及产品替换

总之，不使用外键，避免牵一发动全身。

所有业务逻辑全部在代码里，那么开发者只要关注代码本身就能知道所有业务逻辑。数据库、redis 、mq 等全部是辅助代码逻辑，系统的业务价值核心在于代码。

这段代码，从语法结构上看是 Java 。可以推测这段代码在导出 excel 文件并设置满足条件的指定列进行隐藏。如果是我重构，我能想到的是去除多重 if else ，用 map 集合先保存每个条件，然后一个循环遍历 map 中是否存在满足条件。伪代码如下：

```java

// 业务逻辑外部定义
static Map<String, Function<ExportColumn>> map = new HashMap<>();

static {
map.put("服务器名称", data -> !data.getAppServer().isServerName());
}


// 业务逻辑内

if(map.containsKey(cell.getStringValue())) {
boolean flag = map.get(cell.getStringValue()).apply(dto.getExportColumn());
sheet.setColumnHidden(index, flag);
}

```

我前阵子对自己的开源 web 项目（ https://github.com/woodwhales/woodwhales-music ）增加 2FA 认证功能，也想过这个问题，本打算参考了一下阿里云、腾讯云，结果都没有 2FA ，于是参考了 github 、cloudflare

腾讯云账号密码登录之后，需要小程序扫码再次确认，阿里云同理。其他云服务差不多同理。重点是，这些小程序一般都已经实名认证了，有现成直接用就行了

总结来说，个人觉得：
1 、用户习惯问题，国内用户已经培养成，手机验证码认证。而国外一般老外不喜欢随意暴露更多个人信息
2 、服务成本，虽然 2FA 认证成本更低，但仅仅是对服务开发者，对用户来说丢了恢复码成本太高了。小厂商没有这个 2FA 意识，大厂商觉得我都有用户的人脸、身份信息，有现成的小程序干嘛多加成本开发 2FA 呢，用户万一账号丢失或者盗窃了，活体认证就立马恢复了，用户体验好

d29vZHdoYWxl

可以先看现已上线的系统功能需求，想想自己来设计会怎么设计库表及代码结构。然后看现有代码怎么实现的，存在不合理和合理的，一目了然。
如果项目没有现成的已实现功能，可以列出自己的思路，找同事私下把把关，探讨一下。

最后再配合楼上说的书籍加深理解，上来就看书，太理论，个人觉得对新人不友好。

自推一下，可以自己搭建一个： https://music.icoders.cn/ ，开源地址： https://github.com/woodwhales/woodwhales-music

https://music.cloudcoders.cn 网站源码： https://github.com/woodwhales/woodwhales-music