SQL Server Compact有哪些限制？(或者 - 如何选择在MS平台上使用的数据库？)

Question

我想使用MS Visual C#Express构建的应用程序(如果需要,我愿意升级到标准版)需要数据库.

我对SQL Server Compact感到很兴奋 - 因为我不希望那些将在他们的计算机上安装我的应用程序的人必须安装整个SQL Server或类似的东西.我希望这对最终用户来说尽可能简单.

所以我很兴奋,直到看起来我的表格中的列可以做什么有限.我创建了一个新的数据库,创建一个表,当我去创建列似乎没有一个"文本"数据类型 - 只是一些所谓的"NTEXT"似乎被限制为255个字符."int"似乎限于4(我想要11).并且似乎没有"auto_increment"功能.

这些是我必须忍受的真正限制吗？(或者是因为我使用的是"Express"而不是"Standard").如果这些是真正的限制,那么我的其他数据库选项满足我的要求是什么？(用户是biggie的简易安装 - 我假设我的最终用户只是计算机的普通用户,如果它很复杂会让我的应用程序感到沮丧)

-Adeena

PS:我还希望将我的数据库数据加密到最终用户.我不希望他们能够直接访问数据库表.

PPS.我读过:http: //www.microsoft.com/Sqlserver/2005/en/us/compact.aspx 并没有看到关于这些特殊限制的讨论

Answer 1

我不确定加密,但你可能会发现这个链接很有帮助:http:
//msdn.microsoft.com/en-us/library/ms171955.aspx

至于其余部分:
"Text"和"auto_increment"让我想起了Access.SQL Server Compact应该与SQL Server的服务器版本升级兼容,因为压缩数据库中使用的查询和表应该在不进行修改的情况下传输到完整数据库.考虑到这一点,你应该先了解一下SQL服务器类型和名称,而不是访问的名字:在这种情况下,即varchar(max),bigint和identity列.

不幸的是,你会注意到varchar(max)的失败,因为Compact Edition还没有varchar(max)类型.希望他们能很快解决这个问题.但是,您正在查看的ntext类型支持超过255个字节:实际上是2 ^30个,这相当于超过5亿个字符.

最后,bigint使用8个字节进行存储.您要求11.但是,我认为您可能会感到困惑,存储大小表示可用的小数位数.绝对不是这样的.8字节的存储空间允许最多2 ^64的值,这将容纳超过11位的数字.如果您有这么多项目,那么您可能还需要服务器级数据库.如果你真的想用数字来思考,那么也numeric提供了一种类型.

Answer 2

一些,希望有用的评论:

1st - 不要使用SQLite,除非你喜欢在写入期间锁定整个数据库(http://www.sqlite.org/faq.html#q6),也许更重要的是在.Net应用程序中它不是线程安全的更重要的是它必须重新编译以支持线程(http://www.sqlite.org/faq.html#q6)

作为我当前项目的替代品,我查看了Scimore DB(他们有一个带有ADO.Net提供程序的嵌入式版本:http://www.scimore.com/products/embedded.aspx)但是我需要使用LINQ To SQL作为O/RM所以我不得不使用Sql Server CE.

自动增量(如果你指的是自动键增量)就是它一直以来的例子 - 示例表:

- 表用户

CREATE TABLE Tests (
    Id       **int IDENTITY(1,1) PRIMARY KEY NOT NULL,**
    TestName     nvarchar(100) NOT NULL,
    TimeStamp    datetime NOT NULL
)
GO

至于文字大小,我认为已经回答了.

以下是microsoft technet加密信息的链接:(http://technet.microsoft.com/en-us/library/ms171955.aspx)

希望这个对你有帮助....

Answer 3

不得不引用两个因素:

1. 我经常使用Sql Compact,它非常适合它 - 单个用户,嵌入式数据库,带有单个文件数据存储.它具有所有SQL优点和事务.它对我来说很平常.请注意,此页面上很少有反对者定期使用该产品.不要在服务器上使用它,这不是它的用途.我的许多客户甚至不知道该文件是"数据库",这只是一个实现问题.
2. 您希望加密来自用户的数据 - 可能是因为他们只能从您的程序中查看它.这根本不会发生.如果你的程序可以解密数据,那么你必须将密钥存储在某个地方,并且一个足够专门的攻击者会找到它,句点.

您可能能够很好地隐藏密钥,以便恢复它的努力不值得信息的价值.Windows有一些整洁的机器和用户本地加密例程来帮助.但是如果你的设计强烈要求用户永远不会找到你隐藏在他们计算机上的数据(但是你的程序会)你需要重新设计 - 那个保证人根本无法完成.

Answer 4

SQL CE对我来说是一个难题.我们真的需要另一个不同的SQL数据库平台吗？这是过去几年中第三个针对移动平台的MS ......我不会非常有信心它会成为最后一个.如果有任何技术与SQL Server共享它并不多 - 就我所知,这是一个从头开始的新技术.

我已经尝试过,然后使用SQLite和Codebase取得了更大的成功.

编辑:这是(许多)差异的列表.

Answer 5

ntext支持非常大的文本数据(请参阅MSDN - 这适用于Compact 4.0,但对于您提到的数据类型,同样适用于3.5).

int是一种数字数据类型,因此大小4意味着4字节/ 32位存储(-2,147,483,648到2,147,483,647).如果要在单个列中存储11个字节的数据,请使用varbinary大小为11 的类型.

使用IDENTITY关键字在SQL Server世界中自动递增列.这会导致SQL Server在将数据插入行时自动确定列的值,从而防止与任何其他行发生冲突.

您还可以在SQL Compact中创建密码或加密数据库,以防止用户直接访问您的应用程序.请参阅MSDN上的保护数据库.

您上面提到的所有项目都不是真正的限制,因为他们了解如何使用SQL Server.

话虽如此,SQL Compact有一些限制.

• 不支持 NVARCHAR(MAX)
  • NTEXT 工作得很好
• 不支持VIEWs或PROCEDUREs
  • 这是我认为的主要限制

Answer 6

存在一些限制……乔尔似乎已经解决了细节问题。SQL CE 确实适合移动开发。大多数“嵌入式”数据库解决方案都有类似的限制。查看

• SQLite

  • 无TEXT字段字符数限制
  • INTEGER PRIMARY KEY仅在列上自动递增
  • 一些第三方加密支持

• 埃森特

  • （非托管代码不是我的强项，我无法破译非托管文档）