动态增加数量的可行性。数据库中的表和行
可能的重复:
将多行插入到一张表中或者将行分别插入到多个表中?
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 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
您的问题有很多,获得更多信息会有所帮助,但以下是我的一些想法:
UNION
,至少根据我的经验,通常是一种缓慢的野兽。不关心表管理和数据库的简单性
是一个糟糕的策略。所有编程的最佳实践都适用于数据库设计。请记住,一个不知道你在想什么的人将会继承这个项目,而那个人可能就是你。就我个人而言,我认为我们中的很多人都有过使用 1M 行表的经验,并且我知道我不想将其作为一系列
UNION
来处理,OR
和JOIN
。至少,当桌子设计都是一样的时候不是这样。There is a lot to your question, and it would help to have more information, but here are some of my thoughts:
UNION
, at least in my experience, is generally a slow beast.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
UNION
s,OR
s andJOIN
s. At least, not when it was all the same table design.既然一百万行是一个非常非常小的表,为什么您还要考虑将其分成 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?