我有一个独特的情况。我网站的用户可以提交文章供其他用户审阅,但他们可以按年龄和国家/地区限制谁可以审阅文章。我的问题是,我认为将所有 250 个国家(或他们希望其他用户可见的任何国家)以 JSON 格式存储在数据库。这样我每篇文章只需要一条记录。我不确定性能是否会受到严重影响?该网站将处理 1-2 百万用户,提交审查的文章数量也将相当大。唯一要做的“处理”是每个用户
你们有什么感想?我是否过度认为每篇文章的 250 条记录很多?
我有一个独特的情况。我网站的用户可以提交文章供其他用户审阅,但他们可以按年龄和国家/地区限制谁可以审阅文章。我的问题是,我认为将所有 250 个国家(或他们希望其他用户可见的任何国家)以 JSON 格式存储在数据库。这样我每篇文章只需要一条记录。我不确定性能是否会受到严重影响?该网站将处理 1-2 百万用户,提交审查的文章数量也将相当大。唯一要做的“处理”是每个用户
你们有什么感想?我是否过度认为每篇文章的 250 条记录很多?
我认为将数据存储在查找表中是完全可以接受的。如果将来发生变化,它会为您提供更多的自由,并且只要您很好地索引表,性能就不会受到太大影响。
Mysql 可以轻松处理数十亿条记录的数据。是的,您需要确保您的数据完整性 - 但是向查找表添加一列与更改存储在每条记录中的对象相比突然变得容易得多。
只需确保您正确保存数据 - 因为您没有重复不必重复的信息。将国家/地区保存在一个表中,并在引用它的查找表中保存一个简单的 ID。
简而言之,如果您不打算基于该列查询数据,那么将 Json 数据存储在关系数据库的列中是可以的。
如果您需要根据该列查找数据,那么在排除数据之前必须解析 json 会对性能造成巨大影响,因此这将是一个不可以。
我们在我的工作中以较小的规模遇到了这个问题,并且在数据库中存储属性的 json 效果很好,不会增加非搜索属性的数据库的复杂性。
我会使用另一个表来代替该数据,并创建一个唯一的列来匹配它。
您有一个“国家”表和一个“文章”表。我会制作第三个“国家文章”,只包含应该匹配的索引。毕竟Mysql是关系型的。如果您担心性能,请进行基准测试。
您可以为国家/地区创建一个单独的表,并将其 ID 与文章表一起存储。
您可以将所有国家/地区、亚洲、欧洲、北美、南美等的选项存储在您的国家/地区表中。
JSON 将阻止 DBMS 检查您希望存储的国家/地区的有效性。它基本上是一个不透明的文本,因此 DBMS 不能强制引用完整性(外键)。
即使您不需要查询国家/地区(这是一个相当大的 if),您至少需要在检查特定国家/地区之前解析 JSON。
JSON 可以很好地匹配分层数据,但这只是一个简单的集合(国家或者不是集合的元素),可以通过单独的连接表 ARTICLE_COUNTRY 很好地表示,然后可以有效地维护和搜索:
此联结表将仅链接到可访问文章的国家/地区。如果大多数文章都可以从大多数国家/地区访问,您甚至可以反转联结表的含义并仅存储“禁止”国家/地区,从而降低总行数。