这些嵌入式/快速数据库的 4GB 限制足够好吗？如果达到限制，下一步该怎么办？
我想知道（理论上）桌面应用程序可以消耗这些 Express/嵌入式数据库产品（SQL-Server Express、Oracle Express、SQLite3 等）的全部 4GB 限制多长时间，前提是大 blob 将存储在文件系统中。
另外，当它达到 4GB 时，您的策略是什么？
- 归档旧数据库
- 将 1-3 个月的数据复制到新数据库（将此视为缓存策略？）
- 从此时开始使用新数据库（如何访问旧数据？）
我知道答案可能会有所不同，具体取决于关于您在表/列中存储了多少数据。但请根据您的经验进行描述（什么样的桌面应用程序，写入/读取繁重，根据您的猜测会达到多长时间）。
I'm wondering how long a (theoretically) desktop-app can consume the full 4GB limitation of these express/embedded database products (SQL-Server Express, Oracle Express, SQLite3, etc) provided that big blobs will be stored in filesystem.
Also what would be your strategy when it hits the 4GB?
- Archive the old DB
- Copy 1-3 months of data to the new DB (consider this as cache strategy?)
- Start using the new DB from this point onward (How do you access the old data?)
I understand that the answer might varies depending on how much data you stored in the table/column. But please describe based on your experience (what kind of desktop-app, write/read heavy, how long will it reach according to your guess).
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
除了建议升级到“真正的”数据库之外，确实没有办法回答这个问题。话虽这么说，如果单用户数据库达到 4GB 而没有容纳大型 blob，那么您正在做一些不寻常的事情。
编辑
许多人忽略的一件事是 SQL Server Express 版本的 RAM 和 CPU 限制。虽然 2008 及更早版本的数据库大小限制为 4GB（2008 R2 为 10GB，如该问题的评论中所指出的），但您更有可能受到 1GB RAM 和单 CPU 限制的负面影响，尤其是 数据集那么大。
归档（几乎）从来都不是一个简单的解决方案，因为这通常涉及破坏现有关系或复制数据。例如，假设我有一个包含
客户和订单的数据库。这里自然的选择是在两个
CustomerID列之间创建一个外键，使其在Order表中不可为 null。但是当我想存档订单时会发生什么？我要么必须破坏存档数据库中的关系（允许它链接到存档数据库中不存在的CustomerID），要么必须复制数据（存档链接的客户记录，同时仍将其保留在实时数据库中）。从维护的角度来看，这两种选择都不是特别理想的。There is really no way to answer this question, other than to advise upgrading to a "real" database. That being said, if a single-user database is reaching 4GB without holding large
blobs, then you're doing something out of the ordinary.Edit
One thing that many people neglect to consider is the RAM and CPU restriction on the Express edition for SQL Server. While 2008 and prior have database size limits of 4GB (10GB for 2008 R2, as pointed out in the comments for this question), you're far more likely to be negatively impacted by the 1GB RAM and single CPU limitations, especially with data sets that large.
Archiving is (almost) never a simple solution, since that usually involves either breaking existing relationships or duplicating data. For example, consider I have a database of
Customers andOrders.The natural choice here is to create a foreign hey between the two
CustomerIDcolumns, making it non-nullable in theOrdertable. But what happens when I want to archive the orders? Either I have to break the relationship in the archive database (allowing it to link to aCustomerIDthat doesn't exist in the archive database) or I have to duplicate the data (archive the linkedCustomerrecord, while still keeping it around in the live database). Neither option is particularly desirable from a maintenance perspective.我对于“达到 4GB 时会发生什么”的策略通常是“安装一个成熟的数据库”。
4 GB 的文本量非常大；对于单个开发人员应用程序来说，它几乎是无限的。
假设文件系统使用 blob，将用户的图像限制为每个图像 100kb，每个用户一个配置文件图像，并且这些图像不超过数据库的四分之一； 1 GB。那仍然是一万用户。
4GB 通常很多，除非您正在做一些不寻常的事情。
My strategy for "what happens when it hits 4GB" would usually be "install a full-fledged database".
4 GB is an awful lot of text; consider it nearly infinite for a single-developer application.
Assuming blobs to the filesystem, limit users' images to 100kb per image, one profile image per user, and no more than one quarter of your database to those images; 1 GB. That's still ten thousand users.
4GB is usually a lot, unless you're doing something unusual.
“如果达到限制，接下来怎么办？”
这个数字：18446744073709551615。如果你没有得到它，那就是 16 艾字节（减一）。
"what’s next if limitation is reached?"
this number : 18446744073709551615. And in case you didn't get it, that's 16 exabyte (minus one).
如果达到限制，则使用没有该限制的 DBMS。另外，请永远记住，没有免费软件之类的东西。
If the limit is reached then use a DBMS that doesn't have that limitation. Also, always remember that there is no such thing as free software.