为什么要好好设计数据库，或者说设计不好有什么恶果。

一个糟糕的数据库设计会额外的人员消耗，还要影响开发人员情绪，频繁的操作一个*队友设计的数据库会是个什么状态？
‌情绪崩溃‌：每天需要处理复杂的SQL查询、冗余的数据逻辑，甚至因数据库问题导致线上故障，容易产生挫败感。
‌效率低下‌：原本1小时完成的任务，可能因数据库设计问题需要3小时甚至更久。
‌代码质量下降‌：为了快速“绕过”数据库问题，开发者可能写出更多“hack”代码，进一步加剧系统复杂性。
‌离职风险‌：长期处于低效、高压力的工作环境，可能导致团队成员流失。

如果与其他团队或者第三方合作，第三方会怎么想？
专业形象受损‌：
第三方可能认为合作方技术能力不足，缺乏对基础架构的重视。
例如：API接口因数据库设计问题响应缓慢，第三方可能质疑合作方的整体技术实力。
‌合作效率降低‌：
第三方需要投入更多时间适配合作方的数据库设计（如自定义字段、复杂关联查询）。
例如：数据对接时，因表结构不规范，第三方可能需要额外开发数据转换逻辑。
‌长期合作风险‌：
第三方可能因数据库设计问题对合作失去信心，甚至转向其他更专业的合作伙伴。
例如：数据迁移或升级时，因设计缺陷导致项目延期，第三方可能要求更高费用或终止合作。


数据库作为一个系统的最低层基础，一旦修改设计将造成不可预估的影响，不到万不得一没人会想走这一步。
‌兼容性问题‌：
表结构调整可能导致旧版本代码报错，甚至引发线上故障。
例如：字段类型变更后，历史数据可能无法正确解析。
‌数据迁移风险‌：
数据迁移过程中可能出现丢失、重复或格式错误。
例如：分库分表时，若迁移逻辑不完善，可能导致部分数据丢失。
‌业务中断‌：
数据库修改可能需要停机维护，影响业务连续性。
例如：金融系统在交易高峰期进行数据库结构变更，可能导致用户无法交易。
‌团队协作冲突‌：
数据库修改可能涉及多个团队（如开发、测试、运维），协调不当易引发冲突。
例如：开发团队未通知测试团队进行回归测试，导致新功能上线后问题频发。


简单点说就是一有人看数据库，设计数据库的人就会挨骂。

常规的数据库设计规约就不说了，至少要避免以下几个恶习：
1.开始之前要先确定统一的命名，不要谁遇到了就随手百度一个，同一个实体或属性在数据库中(整个公司的全部项目全部数据库)只能用同一个单词表示
2.不要用拼音首写，除非是约定俗称的，如RMB
3.任何对象名都不要带减号(中划线)，这个符号在SQL中表示减法。如SELECT A-B FROM FI_USER;是表示A减B 还是"A-B"这一列？
4.不要用驼峰格式命名,应该用下划划分隔,如USER_ID或user_id,尽量大写，大写更好对齐代码看上去会清晰的多。而不是userId。一方面不容易记忆，因为userID也比较合理，另一方面有些数据库会默认强制大写或小写（一般是大写），最后为了避免大小写的混淆，有些程序会把查询结果强制转大写或小写。通常是列名用大写，数据库名(catalog/schema)表名等其他对象用小写，
5.每个表要统一主键，如用户表和角色表的主键都要用ID，而不是USER_ID,ROLE_ID。只有作外键时才用USER_ID,ROLE_ID即使是中间表也需要有一个统一主键(如用户角色表)。这对低层框架的设计和统一操作尤为重要，在许多情况下数据操作需要用到主键(如SQL Server的分页)，如果不统一就需要多一个参数，如果是多个表就要传多个参数，在查询、删除、更新、去重插入时都需要多列条件去定位行，后续操作会非常麻烦。
6.表名不要加统一的tab前缀，其他对象应该加前缀,如视图用v_开头或uv_开头。但是都要加模块前缀如如销售分销订单表用sd_order,v_sd_order而不是tab_sd_order