0

这是一个复杂的问题,所以我将尝试简化它。

我的服务器上有一个 mysql 实例,托管了许多用于不同目的的模式。这些模式通常(不完美)以EAV方式构建。我需要定期将信息移入和移出该结构。

示例 1:为了在网页上显示信息,我获取信息,将其粘贴到一个复杂对象中,然后通过 json 将其传递给网页,在网页中将 json 转换为复杂的 javascript 对象,然后我将其与淘汰赛和类似的东西。

结论:这导致很多逻辑被放在多个地方,以便我可以将页面上的值与数据库中的值相关联。

Example2:为了让用户可以从 pdf 中导入信息,我在 pdf 表单字段中存储了很多信息。在这种情况下,我没有编写 pdf,因此表单字段的命名方式没有使所有这些逻辑都足够容易为CRUD编写 3 次或更多次。

结论:这导致我将 pdf 表单字段列表复制到数据库中的表中,以便我可以以某种方式将它们与应放置数据的位置相关联。出现的问题是 pdf 上的字段需要与 schema.table.column 关联,而我发现存储该信息的唯一方法是通过VARCHAR

这两个示例都没有涉及少量数据(例如示例 1 中的 6 个表和示例 2 中的大约 1400 个 pdf 表单字段)。鉴于Example1和生成的逻辑存储在多个位置,构建Example2似乎是合乎逻辑的,我可以将数据之间的关系存储在数据库中,在那里它们可以被一致地访问和更改,并且适用于所有涉及的方法。

现在,很可能我只是很愚蠢,而且我所有的谷歌搜索都没有发现有一种简单的方法可以将这些数据与正确的 schema.table.column 相关联如果是这种情况,那么告诉我正确的方法这样做是简单的答案。

但是,这就是我感到困惑的地方。我一直被告知,您永远不想在数据库中存储有关数据库的信息,尤其是不作为字符串 (varchar)。这在很多层面上似乎都是错误的,我只是不知道我是否愚蠢,最好遵循Example1或者这里是否有一些关于数据库结构的技巧我错过了。

4

1 回答 1

1

不知道你从哪里得到“......从不......在数据库中存储有关数据库的信息”。对于 EAV 模型,通常将元模型(实体类型及其允许的属性)存储在数据库本身中,以便它是自描述的。如果您必须更改元模型,您更愿意更改代码还是表中的几行?

EAV 数据库的主要缺点是您失去了进行简单连接的能力。连接类型的操作变得更加复杂。就像生活中的其他事情一样,您会根据自己的要求进行权衡。我已经看到自我描述的 EAV 架构非常成功地使用。

于 2012-04-10T23:55:48.537 回答