每月增加一个的数据库，我应该使用哪种设计策略？
我有一个每月都在增加的数据库。架构保持不变，所以我想我使用以下两种方法之一：
仅使用一个表，新数据将附加到该表中，并由日期列标识。每个月增加的数据大约是20,000行，但从长远来看，我认为搜索和分析这些数据应该是个问题
每月动态创建一个表，表名会指示它包含哪些数据（例如， Usage-20101125)，这将迫使我们使用动态 SQL，但从长远来看，似乎没问题。
我必须承认我没有设计这种数据库的经验。在现实世界中我应该使用哪一个？
太感谢了
I have a database that increases every month. The schema remains the same, so I think I use one of these two methods:
Use only one table, new data will be appended to this table, and will be identified by a date column. The increasing data every month is about 20,000 rows, but in long term, I think this should be problem to search and analyze this data
create dynamically one table per month, the table name will indicate which data it contains (for example, Usage-20101125), this will force us to use dynamic SQL, but in long term, it seems fine.
I must confess that I have no experiences about designing this kind of database. Which one should I use in real world?
Thank you so much
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
每月 20 000 行并不是很多。选择你的第一个选择。您没有提到您将使用哪个数据库，但 SQL Server、Oracle、Sybase 和 PostgreSQL（仅举几例）可以轻松处理数百万行。
您需要研究适当的维护计划，包括索引和统计数据，但这需要大量的阅读和经验。
20 000 rows per month is not a lot. Go with your first option. You didn't mention which database you'll be using, but SQL Server, Oracle, Sybase and PostgreSQL, to name just a few, can handle millions of rows comfortably.
You will need to investigate a proper maintenance plan, including indexing and statistics, but that will come with lots of reading and experience.
查看对表进行分区。
这样，您可以将数据物理存储在不同的磁盘上以提高性能，而逻辑上它将是一个表，以便您的数据库保持良好的设计。
Look into partitioning your table.
That way you can physically store the data on different disks for performance while logically it would be one table so your database stays well designed.