Что ограничения к Компактному SQL Server? (Или - как каждый выбирает базу данных для использования на платформах MS?)

Некоторые, надо надеяться, полезные комментарии:

1-й - не используют SQLite, если Вам не нравится иметь необходимость заблокировать всю базу данных во время записей (http://www.sqlite.org/faq.html#q6), и возможно что еще более важно, в приложении .NET это НЕ является ориентированным на многопотоковое исполнение или главным, это должно быть перекомпилировано для поддержки потоков (http://www.sqlite.org/faq.html#q6)

Как альтернатива для моего текущего проекта я посмотрел на DB Scimore (у них есть встроенная версия с поставщиком ADO.NET: http://www.scimore.com/products/embedded.aspx), но я должен был использовать LINQ Для SQL как O/RM, таким образом, я должен был использовать SQL-сервер 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)

Надежда это помогает немного....

I must also chime in here with VistaDB as an alternative to SQL CE.

VistaDB does support encryption (Blowfish), it also supports TEXT as well as NTEXT (including FTS indexes on them).

And yes the post above is correct in that you have to look at the SQL Server types to really match them up, VistaDB also uses the SQL Server types (we actually support more than SQL CE does; only missing XML).

To see other comparisons between VistaDB and SQL CE visit the comparison page. Also see the SO thread on Advantages of VistaDB for more information.

(Full disclosure - I am the owner of VistaDB so I may be biased)

Я использовал различный SQL Server Компактные выпуски в нескольких случаях, но только когда-либо как репозитории сбора данных на мобильных платформах - то, где он работает хорошо на синхронизацию с базой данных сервера, и с таким сценарием, является, несомненно, дополнительным выбором.

Однако, если бы Вам нужно что-то, чтобы сделать больше, чем это и действие как основная база данных к Вашему приложению тогда, я предположил бы, что SQLLite является, вероятно, более оптимальным вариантом, это абсолютно твердо, широко поддерживаемое и найденное во всех видах мест (используемый на iPhone, например), но удивительно способно (Средство моделирования Виртуальной реальности , OpenSim использует его, поскольку это - база данных по умолчанию) и существует партии других (включая Microsoft).

CE SQL является загадкой для меня. Нам действительно была нужна еще одна различная платформа базы данных SQL? И это является третьим за прошлые несколько лет, предназначенных для мобильных платформ от MS... У меня не было бы большой уверенности, что это будет заключительное. Это не совместно использует много, если какая-либо технология с SQL Server - это - новое с нуля, насколько я могу сказать.

я попробовал его, и затем был более успешным и с SQLite и с Кодовой базой.

РЕДАКТИРОВАНИЕ: Вот список из (много) различия.

Я не уверен в шифровании, но Вы, вероятно, найдете эту ссылку полезной:
http://msdn.microsoft.com/en-us/library/ms171955.aspx

Что касается остальной части его:
"текст" и "auto_increment" напоминают мне о Доступе. Компактный SQL Server, как предполагается, является обновлением, совместимым с сервер выпуски SQL Server в этом, запросы и таблицы, используемые в Вашей компактной базе данных, должны передать полной базе данных без модификации. Имея это в виду, необходимо сначала посмотреть типы SQL Server и имена , а не имена Доступа: в этом случае а именно, varchar(max), bigint, и identity столбцы.

, К сожалению, Вы заметите, что это перестало работать относительно varchar (макс.), потому что Компактный Выпуск еще не имеет varchar (макс.) вводят. Надо надеяться, они скоро зафиксируют это. Однако тип ntext Вы смотрели на поддержки больше чем 255 байтов: 2 <глоток> 30 на самом деле, который составляет больше чем 500 миллионов символов.

Наконец, bigint использует 8 байтов для устройства хранения данных. Вы попросили 11. Однако я думаю, что Вы можете быть смущены здесь, что размер ресурса хранения указывает на количество доступных десятичных цифр. Это - определенно НЕ случай. 8 байтов устройства хранения данных допускают значения до 2 <глоток> 64 , который разместит больше чем 11 цифр. Если у Вас есть это много объектов, Вы, вероятно, хотите базу данных класса сервера так или иначе. Если Вы действительно хотите думать с точки зрения цифр, существует numeric тип, обеспеченный также.

Существуют ограничения... Joel, кажется, обратился к деталям. CE SQL действительно приспособлен для мобильной разработки. Большинство "встроенных" решений для базы данных имеет подобные ограничения. Выезд

• предел символа поля SQLite

  • No TEXT
  • Автоматический инкремент только на INTEGER PRIMARY KEY столбец
  • Некоторое третье лицо поддержка шифрования

• Esent

  • (неуправляемый код не является моей сильной стороной, и я не могу дешифровать неуправляемые документы )