这是一个复杂的问题,所以我将尝试简化它。
我的服务器上有一个mysql实例,托管了许多用于不同目的的模式。模式通常以EAV方式构造(不完美)。我需要定期将信息转入和转出该结构。
例子1 :为了在网页上显示信息,我获取信息,将其粘贴到一个复杂的对象中,然后我将其通过json传递到网页,在那里我将json转换为一个复杂的javascript对象,然后我用knockoutjs和类似的东西来呈现。
结论:这导致将 lot 逻辑放入多个位置,以便我可以将页面上的值与数据库中的值相关联。
Example2 :为了允许用户从pdf导入信息,我在pdf表单字段中存储了大量信息。在这种情况下,我没有编写pdf,因此表单字段的命名方式不是所有这些逻辑都足以为CRUD写入3次或更多次。
结论:这导致我将pdf表单字段列表复制到数据库中的表中,这样我就能以某种方式将它们与应放置数据的位置相关联。出现的问题是pdf上的字段需要与schema.table.column关联,我发现存储该信息的唯一方法是通过VARCHAR
这两个示例都没有提到少量数据(例如,示例1中的6个表格,以及示例2中的大约1400个pdf表单字段)。给定 Example1 并将结果逻辑存储在多个位置,构建 Example2 似乎合乎逻辑,我可以在数据库中的数据之间存储关系可以一致地访问和更改所有相关方法。
现在,我很可能只是愚蠢而且我所有的Google搜索都没有遇到过将这些数据与正确的schema.table.column相关联的简单方法。如果是这种情况,请告诉我正确的方法就是这里的简单答案。
然而,这是我感到困惑的地方。我一直被告知你永远不想在数据库中存储有关数据库的信息,尤其不是作为字符串(varchar)。这似乎在很多层面上都是错误的,我只是无法弄清楚我是不是很愚蠢,而且最好遵循 Example1 或者如果这里有一些技巧我错过了数据库结构。
答案 0 :(得分:1)
不知道你在哪里“......永远不会......在数据库中存储有关数据库的信息”。使用EAV模型,将元模型(实体类型及其允许的属性)存储在数据库本身中是正常的,这样它就是自我描述的。如果你不得不改变元模型,你宁愿改变表中的代码还是几行?
EAV数据库的主要缺点是您失去了进行简单连接的能力。连接类型的操作变得更加复杂。像生活中的其他一切一样,您可以根据您的要求进行权衡。我已经看到非常成功地使用了自我描述的EAV架构。