【问题标题】:Can I have one million tables in my database?我的数据库中可以有 100 万张表吗?
【发布时间】:2015-03-01 22:16:50
【问题描述】:

在我的数据库中拥有 100 万个表会有任何优点/缺点吗?

我正在尝试实现 cmets。到目前为止,我可以想到两种方法来做到这一点: 1. 将所有帖子中的所有 cmets 放在 1 个表中。 2. 每个帖子都有一个单独的表,并将该帖子中的所有 cmets 存储在相应的表中。

哪个更好?

谢谢

【问题讨论】:

  • 第一个。祝你好运尝试用每个帖子的表来管理你的数据库——这太疯狂了。我将添加更多有用的信息。您应该有一个帖子表和一个 cmets 表。数据库引擎旨在有效处理大量数据,只要您在 post_id 列等上添加索引,您就不应该遇到太多麻烦/延迟/响应时间

标签: mysql database postgresql social-networking


【解决方案1】:

最好有一个用于 cmets 的表,其中包含一个字段,用于标识每个评论所属的帖子 ID。如果您这样做,编写查询以获取给定帖子 ID 的 cmets 会容易得多,因为您不需要首先动态确定您正在查看的表的名称。

我在这里只能代表 MySQL(不确定这在 Postgresql 中是如何工作的),但请确保在 post id 字段上添加索引,以便查询快速运行。

【讨论】:

    【解决方案2】:

    可以拥有一百万张表,但出于多种原因这可能并不理想[*]。经典 RDBMS 通常被部署和优化用于在数百/数千个表中存储数百万/数十亿行。

    至于你试图解决的问题,正如其他人所说,使用外键来关联一对表:posts & cmets a la [MySQL syntax]:

    create table post(id integer primary key, post text);
    create table comment(id integer primary key, postid integer , comment text, key fk (postid));
    

    {您可以添加约束来强制评论和帖子之间的引用完整性以避免孤立的 cmets 但这需要存储引擎的某些功能才能有效}

    主键 ID 的生成留给读者,但像自动递增这样简单的事情可能会让您快速入门 [http://dev.mysql.com/doc/refman/5.0/en/example-auto-increment.html]

    哪个更好?

    除非这是一项家庭作业,否则将这种材料存储在经典的 RDBMS 中可能不适合现代习语。保持相同的精神模式并使用 SOLR/Elasticsearch 之类的东西来存储您的材料并从内容索引中受益,因为我相信您会想要避免编写自己的搜索引擎?您可以使用 sphinx [http://sphinxsearch.com] 之类的东西以相同的方式索引 MySQL。

    [*] 如果没有一些非常规的架构结构,元数据的数量和底层文件系统上的压力将是有问题的(例如,一些过时的/传统的存储引擎,如 MySQL 上的 MyISAM 将在每个表中创建三个文件)。

    【讨论】:

      【解决方案3】:

      在使用关系数据库时,您必须了解(稍微了解一下)规范化。 third normal form (3NF) 易于理解,几乎适用于任何情况。可以在here 找到一个简短的教程。如果需要更多/其他/更好的示例,请使用 Google。

      每条记录一个表是红灯,你知道你错过了一些东西。这也意味着您需要动态 DDL,当您有新记录时,您必须创建新表。这也是一个安全问题,数据库用户需要很多权限,成为安全隐患。

      【讨论】:

        猜你喜欢
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 2021-12-08
        • 2013-04-23
        • 1970-01-01
        • 2022-01-04
        • 2011-03-07
        • 2011-01-31
        相关资源
        最近更新 更多