有人对在数据库中创建元表有什么建议吗？这些表将用于模拟数据库中的表，使用数据库。这是为了当您想要轻松地将结构（更多字段）动态添加到数据库中而不必担心所涉及的所有技术细节时。我唯一的例子是这样的：
表：MetaTables 字段：tableName、tableDescription
表：元字段字段：tableName、fieldName、fieldDesc、fieldDesc
表：元代码字段：tableName、fieldName、codeName、codeValue 等...
我以前从未真正使用过这样的东西，并且想知道是否有任何“陷阱”需要注意。
这样的事情是否可以合理维护，或者你会反对它吗？
您所说的是一种灵活的模式模型，通常称为开放模式模型或实体属性值模型。谷歌这些，你会得到很多参考资料和文章。
我还建议您不要回避添加列的设计。当设计中的波动程度并不那么重要时，我经常看到人们采取这样的方法。编写创建新数据容器（表、列等）的脚本并不难。
我认为采用完全实现的关系数据库，忽略几乎所有功能，并在关系数据库之上构建自己的关系数据库的想法是等待发生的麻烦。
建立自己的模型听起来很“酷”。
当然，您必须建立自己的元级空间管理。那是颈部的中度疼痛。
查询执行、优化、索引处理等相对复杂。
然后，还有事务、锁定、死锁检测等。这真的很难纠正。但是，一旦你让它工作，它就会有一个巨大的“酷”因素。
此外，您还需要发明一个 API。ODBC 在低级别工作，而您希望在更高级别工作，因此您必须发明自己的“酷”版本的 ODBC。
“酷”因素最能胜过所有这些工作。您将花费数年时间才能使其正常工作。
正如 keithwarren7 建议的那样，做一些谷歌搜索，你会看到（根据你的评论）这样做完全不酷。（好吧，在某些情况下是这样，但几乎总是不是，IMO。）
很酷，而且比您想象的要少得多的是，以它们预期的使用方式使用关系数据库，并具有经过深思熟虑的模式设计。您会发现这为您提供了更好的数据完整性、性能、使用更少的存储空间，并且通常比实体-属性-值模型更容易使用。您将阅读到一些明显的陷阱，例如，您将自己负责执行引用完整性，而不是数据库。
无论如何，在你继续之前仔细研究这个想法（超越stackoverflow），因为一旦你实现了这种方式，改变你的想法真的很重要。
大多数情况下，元表模式首先破坏了使用关系数据库的目的。除了基本的事务/ACID 属性外，关系数据库在向系统添加两大功能方面最有用：a) 与报告生成器等应用程序共享数据，b) 允许临时查询。
如果以上两种都不适用并且您仍然希望通用，则其他一些数据持久性解决方案可能会更好。您可以非常优雅地在 Berkley DB 之类的东西中推出自己的解决方案，或者尝试对通用模式进行变体：
http://theprogrammersparadox.blogspot.com/2008/06/structuring-noun-verb-data.html
保罗。
我同意说 EAV 看起来很酷但并不酷的评论。它做了很多工作，结果证明是次要的或完全适得其反。
我使用自己的包含元数据的用户表的地方是为了比较两个不同的数据库以找出它们的分歧点。比较两个结构相同的模式之间的值很简单。检测模式之间的差异更加微妙，并且涉及比较元数据。
我的方法是将两个或多个数据库的元数据表中的数据复制到我的“元数据库”中用户定义的元数据表中，然后进行比较。大约一个小时后，我发现一个列在一个数据库中定义为实数，在另一个数据库中定义为整数。这几个月来一直对 DBA 隐藏。我还发现一个或另一个数据库中缺少几列。
今天，有一些工具可以为您进行这种比较。但是，如果您了解 DBMS 为您构建的系统表的架构，那么您自己的操作并不难。
您始终可以使用 XML 数据的单个字段，而不是使用表和字段来表达动态结构。许多主流 RDBMS 允许在 XML 中索引属性/元素，因此您的查询甚至可能是高性能的。
抱歉，正如其他海报所指出的那样，这确实是在重新发明轮子。
如果要使用这些数据，大多数数据库都有包含数据库模式的表。这可以用于反射的目的。
任何好的数据库手册都应该告诉您如何访问这些表。
对一个大型 eav 表中的大型数据集进行一些性能测试。如果你的老板看到表现缓慢，他/她不会使用“酷”这个词。