小编Agi*_*ief的帖子

TL;DR：证明在实践中，alter table table_name drop foreign key constraint_name语句的执行不会破坏现有数据。重要的考虑是语句本身的执行；考虑无关紧要的事后数据更改。（打个比方：打开马厩门是有害的行为，而不是马螺栓。）

我和我的老板对于是否在 MySQL/InnoDB 数据库中使用外键有不同的看法。我赞成使用它们来强制执行 RI 并利用ON DELETE CASCADE和ON UPDATE RESTRICT/ SET NULL，而他反对（相信他可以在应用程序级别强制执行 RI）。

他的论点主要是：

1. Drupal 不使用它们，没有它们也能正常工作，那我们为什么要这样做呢？
2. 当您需要更改数据和/或结构时，它们太不灵活了。
3. 他已将它们从现有表中删除以进行更改，这导致数据损坏仅在数周或数月后才在高流量/高活动站点上引起注意，因此他宁愿不使用它们。

我的论点主要是：

1. 并非 Drupal 5-7（MyISAM、SQLite 3）支持的所有数据库/数据库引擎默认都强制执行FK，因此 Drupal 仅将它们保留为文档，而这在 D8 中可能有所不同。
2. 是的，它们可能很难处理，但也许问题在于开发人员的规划/设计不当，而不是 FK。
3. 当然，在 DBMS 级别不使用 FK 强制执行 RI 比其他方式更有可能导致数据损坏。（例如，当现有内容引用必须具有特定状态的用户时，D6 的用户引用模块不限制更改用户状态）。
4. 让代码做/尝试 DBMS 已经做的事情是在浪费时间和资源。他如何保证他的代码与 DBMS 一样好（或比 DBMS 更好）？

从本质上讲，如果我能证明删除外键本身的行为（无论后续数据插入/更新如何）不会破坏现有数据，他就会认同我的想法。我看不出有什么方法可以证明它们的有用性/优势，因为我不确定如何令人满意地观察/记录drop foreign key执行后立即产生的效果，而不是将执行前的数据与执行后的数据进行比较。

那么，我如何通过证明以后删除/更改外键的行为不会破坏现有数据，而使用它们不会导致任何问题来说服我的老板我们应该使用外键？我如何最好地设置实际使用测试？

注意：我不太想证明我使用 FK 是正确的（从自负的角度来看），但是在 DBMS 级别使用它们比在应用程序代码中使用它们更有益于数据和应用程序代码等级。

在 Oracle 12c 中，可以AUTO_INCREMENT通过使用关键字/短语来使用功能GENERATED ALWAYS AS IDENTITY。这对我来说似乎很麻烦/笨拙，因为在我习惯的其他 SQL 方言（SQLite、MySQL）中，使用关键字AUTO_INCREMENT或AUTOINCREMENT.

是否可以创建别名/快捷方式/makro/函数来让 Oracle 将其AUTO_INCREMENT视为与GENERATED ALWAYS AS IDENTITY? （我不建议将编辑源代码作为一种实用的解决方案。我宁愿提交功能请求。）