未定义的数据库架构答案

【问题标题】：Not defined database schema未定义的数据库架构
【发布时间】：2015-04-24 08:19:11
【问题描述】：

我有一个包含 220 个表的 mysql 数据库。数据库是结构化的，但没有任何明确的关系。我想找到一种方法将每个表的主键连接到其对应的外键。我正在考虑编写一个脚本来发现两列之间可能的关系：

这些功能不足以解决问题。你有什么想法我可以更准确和更接近解决方案。另外，如果有任何可用的工具可以做到这一点。

请指教！

【问题讨论】：

(1) MyNONsql 没有目录，可以通过它们的 NONsql 访问，以获得 PK::FK 引用吗？？？我使用过的每个 SQL 都是这样，这是 SQL 合规性要求。 (2) 如果它没有“明确的关系”，那就证明它不是“结构良好”。
内容数据结构良好，数据连接良好。这可能来自应用程序级别。另一方面，我需要通过查找表之间的功能依赖来增强数据库。
好的，所以 myNONsql 没有目录，因此它不是 SQL。好的，所以（x）数据结构良好，但（a）结构未知，（b）无法识别。 (x) 与 (a) 和 (b) 存在激烈矛盾。
我添加了更多细节和解释，请查看。随意在 cmets 中提问，或向问题添加细节（使用 EDIT 部分）。

【解决方案1】：

听起来您有一个许可的应用程序+RFS，并且您想要保存数据（这是属于组织的资产），并放弃该应用程序（由于问题已超过可接受的阈值）。

无时无刻不在发生。在这种情况发生之前，人们不会意识到他们的数据是宝贵的，它比任何应用（无论好坏、内部或第三方）都寿命长。

如果它是一个诚实的 SQL 平台，它将具有符合 SQL 的目录，并且目录将包含每个引用的条目。该目录是入门级 SQL 合规性要求。访问目录和提取 FOREIGN KEY 声明所需的代码很简单，并且是用 SQL 编写的。

MySQL、PostgreSQL 和 Oracle 等显然不合规的数据库欺骗性地将自己定位为“SQL”，但它们没有基本的 SQL 功能，例如目录。我想你得到了你所支付的。

解决方案

对于 (a) 此类数据库，例如您的 MySQL，以及 (b) 放置在没有 FOREIGN KEY 声明的诚实 SQL 容器中的数据，我会使用以下两种方法之一。

第一偏好。

现在您可以在 SQL 中完成所有这些操作，但是那样的话，代码会很糟糕，而且 SQL 并不是为此而设计的（表比较）。这就是为什么我会使用awk 的原因，在这种情况下，代码（对于有经验的编码人员）很复杂（给定 220 个文件）但很简单。这完全符合awks 的设计和目的。这将花费更少的开发时间。

我不会尝试在此处提供代码，要识别的依赖项太多，这将是不成熟和原始的。

根据 Codd 的关系模型 的要求，关系键将每个表中的每一行与其相关的任何其他表中的行关联（“链接”、“映射”、“连接”）到，按钥匙。这些 Key 是自然 Key，通常是复合 Key。键是数据的逻辑标识符。因此，编写awk 程序或SQL 代码来确定：

这是一个非常直接的问题，因为键是可见的，可识别的。

这对于从数据库导出到其他系统的数据也非常重要（这正是我们在这里尝试做的）。 键对组织有意义，而该意义超出了数据库。因此进口很容易。 Codd 专门在 RM 中写到了这个值。

这只是关系键的价值，对它们的绝对需求，受到赞赏的众多场景之一。

相反，如果您的记录归档系统没有关系键，那么您就被塞满了，而且塞得满满当当。 IDs 实际上是文件中的记录号。它们都有相同的范围，比如 1 到 100 万。不可能将一个文件中的任何给定记录号与其在任何其他文件中的出现关联起来，因为记录号没有意义。

记录编号是物理的，它们不能识别数据。

我看到一个记录号 123456 在发票文件中重复出现，现在其他文件与什么有关？每个其他可能的文件、供应商、客户、零件、地址、信用卡，只要出现一次，都有一个记录号 123456！

而使用关系键：

我看到IBM 加上一个序列 1, 2, 3, ... Invoice 表中，现在是什么 其他这与表有关吗？ IBM唯一出现过一次的表是 Customer 表。

这个故事的寓意，铭刻在人们的脑海中，就是这样。实际上有一些，即使将它们限制在这个问题的上下文中：

【讨论】：