计算 SQL-Server CE 的存储要求
我有可能将数据推送到第 3 方 Windows Phone 应用程序上的 SQL-ce，但我没有地方进行测试，因此我需要计算是否会超过 4Gb 最大数据库大小（数百万个）记录）。
我知道各种数据类型的大小，但是对索引、行 ID 等是否有额外的要求。此外，这些数据需要同步/复制，所以我假设每行也需要 GUID 等？
表1（前2个字段是聚集主键） nvarchar(20) 整数 整数 datetime
Table2（第一个字段是主键） 整数 整数 datetime
Table3（前两个字段是聚集主键） 整数 整数 int
我可以访问 Sql Server（不是 CE），但我是 Oracle 人员，不太了解那里的方法。任何帮助或见解表示赞赏。
I've got data potentially to be pushed to SQL-ce on a 3rd party windows phone application but I don't have anywhere to conduct a test so I need to figure if we'll exceed the 4Gb max database size (many millions of records).
I know the sizes of various data types but are there additional requirements for indexes, row id's, etc. Also this data will need to be synchronized/replicated so I assume every row needs a GUID or the like as well?
Table1 (first 2 fields are clustered primary key)
nvarchar(20)
int
int
datetime
Table2 (First field is primary key)
int
int
datetime
Table3 (First two fields are clustered primary key)
int
int
int
I have access to Sql Server (not CE) but I'm an Oracle guy and don't know my way around there very well. Any help or insight is appreciated.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
这将是一个起点：http://support.microsoft.com/kb/827968
我有命令行工具可以从 SQL Server 迁移到 SQL Compact，这将为您提供更精确的结果： http://exportsqlce.codeplex .com
此外，合并复制会将列和系统表添加到数据库中。
This will be a starting point: http://support.microsoft.com/kb/827968
I have command line tools to migrate from SQL Server to SQL Compact, that will give you more rprecise results: http://exportsqlce.codeplex.com
Also, Merge replication adds columns and system tables to your database.
幸运的是，您的表非常窄，因此 4 GB 可以扩展到大量行。每行都需要一个 GUID，你是对的。查看 SEQUENTIALID，它将按某种顺序保存您的记录，减少 GUID 的一些性能障碍。您当前是否有权访问数据，或者您是否粗略估计将存储多少记录？如果您有数据，我会创建一个干净的数据库，创建您的表并插入它。根据您的喜好对其进行索引并检查大小。索引可能会占用相当多的空间，但是在这些狭窄的表上您不需要太多索引。
Luckily your tables are very narrow, so the 4 GB can be stretched to a ton of rows. Every row will need a GUID, you're correct. Look into SEQUENTIALID, which will keep your records in some sort of order, reducing some performance hindrances of GUIDs. Do you currently have access to the data, or do you have a rough estimate of how many records you'll be storing? If you have the data I'd create a clean DB, create your tables and insert it. Index it to your liking and check the size. Indexes can take up quite a bit of space, but you shouldn't need much in the way of indexes on these narrow tables.