如何设置一个数据库来跟踪 100k 的价格？产品随着时间的推移？
我想设置一个服务器来存储一段时间内可能超过 100,000 种产品的价格数据。每月将提供一次或两次更新。
我也会有这样的价格的许多组成部分。这样我就用完了 Access 允许的 255 个字段，并且迟早会突破 2 Gig 限制。 （某些产品可能随时会出现新字段）
该项目的规模在某种程度上太小，目前无法让数据库专家建立一个完整的数据库。我可以使用免费的 Microsoft SQL Server 进行快速修复吗？
或者我也会遇到硬件限制？
I would like to setup a server that stores prices data for potentially 100,000+ products over time. Updates will be provided once or twice per month.
I would also have many components of such prices. Such that I run out of the 255 fields that Access allows me, and would burst the 2 Gig limit sooner or later. (New fields might just pop up at any moment for some products)
The scale of this project is somehow too small to get database experts to do a full scale database at the moment. Is there any quick fix I can do with the free Microsoft SQL Server ?
Or I am going to run into hardware limitations also?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您需要更具体地说明您想要什么。如果您使用 255 个字段，那么您的表就会损坏。
但是，为了回答你的问题，像 SQL Server Express 版本这样的东西在处理 100,000 个产品（或者数百万个产品，就此而言，假设你的硬件不错）时完全没有问题。
You need to be more specific about what you want. If you are using 255 fields, then your table is broken.
But, to answer your question, something like the Express edition(s) of SQL Server will have no problem at all handling 100,000 products (or millions of products, for that matter, assuming your hardware is decent).
PostgreSQL 是一种开源数据库管理系统，不像 SQL Server 和 Oracle 的免费版本那样有大小限制。所有 dbms 自然都受到可用磁盘空间和可用交换空间的限制。 （但它们并不都以相同的方式受到限制。）一些免费的 dbms 被限制为使用单个 CPU；我很确定 SQL Server Express 就是其中之一。
大多数 dbms 都有行大小限制。根据 dbms，行大小限制可能是硬限制（无法创建每行存储超过“n”字节的表）或软限制（“长”行——或者至少是其中的一部分—— - 移动到数据库的不同部分，这会影响性能）。
您可以谷歌“行大小限制”，或搜索相同的短语。
查看需要 255 列的价格表的结构和功能依赖性会很有趣。
PostgreSQL is an open source dbms that doesn't have size limitations like the free versions of SQL Server and Oracle do. All dbms are naturally constrained by available disk space and available swap space. (But they're not all constrained the same way.) Some free dbms are constrained to use a single CPU; I'm pretty sure SQL Server Express is one of them.
And most dbms have a row size limitation. Depending on the dbms, the row size limitation might be a hard limit (can't create a table that stores more than 'n' bytes per row) or a soft limit ("long" rows--or at least parts of them--are moved to a different part of the database, which affects performance).
You can google "row size limitation", or search SO for the same phrase.
It would be interesting to see the structure and functional dependencies for a table of prices that needed 255 columns.