动态增加数量的可行性。数据库中的表和行

发布于 2024-11-16 18:16:08 字数 839 浏览 2 评论 0原文

可能的重复:
将多行插入到一张表中或者将行分别插入到多个表中?

100 个包含 10,000 行的表或 1,000 个包含 1,000 行的表哪个更好?

上述问题只是一个基础,没有以下条件就无法完成。

条件:

  • R1-编号。第一种情况的行数。
  • R2-编号第二种情况的行数。
  • T1-编号第一种情况下的表。
  • T2-编号第二种情况下的表。
  • R1 和 R2 动态(急剧)增加,以上给定限制是示例。
  • T1 是常数。
  • T2是动态增加的(与r1成比例)
  • 不关心表管理和数据库的简单性。
  • 只对最短查询执行时间和最短服务器加载时间感兴趣。
  • 数据库 - MySql
  • 语言 - PHP

问题:

  • 查询执行时间和服务器加载时间(最低 RAM 使用量)。
  • 动态增加数量的可行性。数据库中的表。
  • 动态增加数量的可行性。表中的行数。

除了答案之外,还邀请了上述数据库技巧。

Possible Duplicate:
Insert many rows to one table OR insert rows separately to many table?

Which is better 100 tables with 10,000 rows or 1,000 tables with 1,000 rows?

The above question is just a base.Its not completed without the conditions below.

Conditions:

  • R1-No. of rows in first case.
  • R2-No. of rows in second case.
  • T1-No. of tables in first case.
  • T2-No. of tables in second case.
  • R1 and R2 increases dynamically(drastically),above given limit are samples.
  • T1 is constant.
  • T2 is dynamically increase (proportional to r1)
  • Don't care about table management and simplicity of database.
  • Only interested in minimum query execution time and minimum server load time.
  • Database - MySql
  • Language - PHP

Problems:

  • Query execution time and server load time(Minimum RAM usage).
  • Feasibility of dynamically increase in no. of tables in database.
  • Feasibility of dynamically increase in no. of rows in a table.

Along with answers Database tricks for above also invited.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

眉目亦如画i 2024-11-23 18:16:08

您的问题有很多,获得更多信息会有所帮助,但以下是我的一些想法:

  • 与数据库接口的语言通常不是一个因素 - 您应该尽可能努力限制数据库的数量所需的连接和消息(即使用 join 而不是与 PHP 通信两次),但由于良好的设计是在数据库端尽可能多地进行数据选择/排序工作(因为 这就是它们的用途
  • 如果所有表格都有相同的结构,那么在处理大量选择时,通常最好使用一个表 - UNION,至少根据我的经验,通常是一种缓慢的野兽。
  • 如果您确实担心一次只访问一小部分数据,那么我建议将所有内容保留在更少的表中并创建视图。
  • 不关心表管理和数据库的简单性是一个糟糕的策略。所有编程的最佳实践都适用于数据库设计。请记住,一个不知道你在想什么的人将会继承这个项目,而那个人可能就是你。

就我个人而言,我认为我们中的很多人都有过使用 1M 行表的经验,并且我知道我不想将其作为一系列 UNION 来处理, ORJOIN。至少,当桌子设计都是一样的时候不是这样。

There is a lot to your question, and it would help to have more information, but here are some of my thoughts:

  • The language interfacing with the database is generally not a factor -- you should work as hard as possible to limit the number of connections and messages required (i.e. use join instead of communicating with PHP twice), but since good design is doing as much data selection/sorting work on the DB side as possible (because that's what they're for)
  • If all of the tables have the same structure, then you're often better off with one table when dealing with massive selects -- UNION, at least in my experience, is generally a slow beast.
  • If you're really concerned about accessing only a small subset of the data at once, then I would recommend keeping everything in fewer tables and create views.
  • Don't care about table management and simplicity of database is a bad policy. All of the best practices of programming are true for db design. Remember, someone who has no idea what you were thinking will inherit this project, and that might be you.

Personally, I think that quite a few of us have had experience with the 1M line table, and I know that I, for one, would not have wanted to deal with that as a series of UNIONs, ORs and JOINs. At least, not when it was all the same table design.

回首观望 2024-11-23 18:16:08

既然一百万行是一个非常非常小的表,为什么您还要考虑将其分成 100 个表或 1000 个表呢?

Since a million rows is a tiny, tiny table why would you even consider breaking it up into 100 tables or 1000 tables?

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文