我想创建一个名为“NOTES”的表。我以为这个表将包含一个“table_name”VARCHAR（100），它表示放在注释中的表，一个“键”或多个“键”列，表示本注释适用的表的主键值，以及“注意“字段VARCHAR（MAX）。当其他表使用此表时，它们将提供THEIR主键及其“table_name”，并获取与它们提供的主键相关的所有注释。问题是其他表可能有1,2或更多PK，所以我正在寻找关于如何设计这个的想法......
答案 0 :(得分：3)
你提出的建议听起来有点令人费解。我会建议这样的事情。
Notes ------ Id - PK NoteTypeId - FK to NoteTypes.Id NoteContent
NoteTypes ---------- Id - PK Description - This could replace the "table_name" column you suggested
SomeOtherTable -------------- Id - PK ... Other Columns ... NoteId - FK to Notes.Id
这将允许您更好地规范化数据，但仍然可以获得所需数据之间的关系。请注意，这假设您的其他表和Notes中的行之间的关系为1：1。如果这种关系是多对一的，你需要一个交叉表。
看看这个关于数据库规范化的线程
此外，您可以查看此资源以了解有关外键的更多信息
答案 1 :(得分：1)
不要将其他表名和主键放在此表中，而是将NOTES表的主键设置为NoteId。在每个其他表中创建一个FK，用于记录，并将相应的NoteId存储在其他表中。然后，您可以简单地将所有其他表中的NoteId连接到NOTES表。
答案 2 :(得分：0)
当我理解你的问题时，你试图以一种你可能在OOP中抽象类的方式“抽象”多个表的审计。
虽然这是一个很好的OOP设计原则，但由于多种原因，它在数据库中不尽如人意。也许最大的一个原因是，如果你无法想象它，那么稍后看待它的人也不会轻易地重新组装数据。虽然更小，但是当你倾向于将一个表视为一个容器并因此类似于一个对象时，实际上它们是实现这个假想容器的实例，你试图将它们放在一起并且如果你把它们当作这样处理它们会更好地运行。通过创建特定于表或共享结构相似性和数据相似性的表子集的审计表，可以提高数据库的性能，并且不会遇到奇怪的触发器或稍后选择相关问题。
你无法想象它不是因为你不擅长你正在做的事情，而是结构不利于数据库记录。
相反，我建议您创建单独的日志记录表来管理要审核或记录的每个表的审核。事实上，一些快速的谷歌搜索显示已经编写了许多脚本来为您完成大部分任务：Example of one such search
您应该创建这些单独的表，然后如果您希望能够一次报告多个表甚至所有表，您可以创建存储过程（如果要根据条件进行查询）或创建一个视图包含SELECT语句，以对报表类型有意义的方式JOIN和/或UNION表示您感兴趣的表。您仍然需要在视图中编写新对象，但即使使用原始表格设计，您也必须考虑到这一点。