我有一个包含220个表的mysql数据库。数据库将结构化，但没有任何明确的关系。我想找到一种方法将每个表的主键连接到其对应的外键。 我正在考虑编写一个脚本来发现两列之间的可能关系：
这些功能不足以解决问题。您是否知道如何更准确并且更接近解决方案？此外，如果有任何可用的工具，那么。
请建议！
答案 0 :(得分：1)
听起来您拥有许可的应用+ RFS，并且您希望保存数据（属于该组织的资产），并放弃应用（由于问题已超出可接受的阈值）。
一直发生。在这样的事情发生之前，人们不会意识到他们的数据是宝贵的，它会超越任何应用程序，无论好坏，内部或第三方。
如果它是一个诚实的SQL平台，它将具有符合SQL的目录，并且目录将包含每个引用的条目。该目录是入门级SQL合规性要求。访问目录并提取FOREIGN KEY声明所需的代码很简单，它是用SQL编写的。
除非您说＆＃34;没有参照完整性约束，否则它全部由应用层＆＃34;控制，这意味着它不是数据库，它是数据存储位置，记录归档系统，应用程序的奴隶。
在这种情况下，您的数据没有参照完整性
显然NONsqls如myNONsql，PistGREsql和Orable欺骗性地将自己定位为＆＃34; sql＆＃34;，但它们没有基本的SQL功能，例如catalaogue。我想你得到的是你付出的代价。
对于（a）NONsqls，例如myNONsql，以及（b）放置在没有FOREIGN KEY声明的诚实SQL容器中的数据，我会使用两种方法之一。
首选。
使用awk
将每个表加载到数组
将脚本写入：
确定密钥（如果您的＆＃34;密钥＆＃34;是ID字段，您已填充，详情如下）
确定数组键之间的任何引用
现在你可以在SQL中做所有这些，但是，代码将是可怕的，并且SQL不是为此设计的（表比较）。这就是为什么我会使用awk,，在这种情况下代码（对于有经验的编码器）是复杂的（给定220个文件）但是直截了当。这完全在awks设计和目的范围内。这将花费更少的开发时间。
在任何一种情况下，我都不是在征求，只是描述所需的工作范围：我会将其作为有偿工作。我不会尝试在这里提供代码，有太多的依赖关系要识别，这将是不成熟和原始的。
Codd 关系模型所要求的关系密钥相关（＆＃34;链接＆＃34;，＆＃34;地图＆＃34;，＆＃34;连接＆＃ 34;）通过Key，每个表中的每一行与其相关的任何其他表中的行。这些键是自然键，通常是复合键。密钥是数据的逻辑标识符。因此，编写awk程序或SQL代码来确定：
钥匙
Keys其他地方的出现
因此依赖
是一个非常简单的问题，因为键是可见的，可以识别。
这对于从数据库导出到其他系统的数据也非常重要（这正是我们在这里尝试做的）。 键对组织具有含义，并且该含义超出了数据库。因此输入很容易。 Codd在 RM 中专门写了这个值。
这是许多场景中的一个（仅一个），其中关系键的价值，它们的绝对需要，被欣赏，突出显示，提升，放置在壁橱上。真理超越了虚假。在这种情况下，它会破坏任何阅读此内容的人的思想中的虚假。崇拜的时候和燔祭。
批评者被征服了。是时候把它们称为它们了：无知和愚蠢，传播1970年以前的ISAM技术，欺骗性地作为关系数据库理论＆＃34;。相反，如果您的记录归档系统没有关系密钥，那么您就会被填充，并且填补了大量时间。 IDs实际上是文件中的记录号。他们都有相同的范围，比如1到100万。将一个文件中的任何给定记录号与其在任何其他文件中的出现相关联是不合理的，因为记录号没有意义。
记录号是物理的，它们不识别数据。
我在Invoice文件中看到记录号 123456 ，现在其他文件与此有关吗？每个其他可能文件，供应商，客户，零件，地址，CreditCard，仅发生一次，记录编号 123456！
而使用关系密钥：
我在发票表中看到 IBM 加上序列 1,2,3，... ，现在其他表与此有关吗？ IBM 出现一次的唯一表是Customer表。
故事的寓意，蚀刻成一个人的心灵，就是这样。实际上有一些，即使将它们限制在这个问题的背景下：
如果您需要关系数据库，使用关系密钥，不使用记录ID
如果您需要参照完整性，使用关系密钥，不使用记录ID
如果您的数据很珍贵，使用关系密钥，不使用记录ID
如果您要导出/导入数据，使用关系密钥，不使用记录ID
如果你曾经有人传播记录ID，为了人性，请拍摄它们。