GUID или ключ сущности int с SQL Compact / EF4? - PullRequest
1 голос
/ 20 марта 2010

Это продолжение более раннего вопроса , который я разместил на ключах сущностей EF4 с помощью SQL Compact. SQL Compact не допускает сгенерированные сервером идентификационные ключи, поэтому мне остается создавать свои собственные ключи, когда объекты добавляются в ObjectContext. Моим первым выбором будет целочисленный ключ, а предыдущий ответ связан с сообщением в блоге , в котором показан метод расширения, использующий оператор Max с выражением выбора для поиска следующего доступного ключа:

public static TResult NextId<TSource, TResult>(this ObjectSet<TSource> table,  Expression<Func<TSource, TResult>> selector) 
    where TSource : class
{
    TResult lastId = table.Any() ? table.Max(selector) : default(TResult);

    if (lastId is int)
    {
        lastId = (TResult)(object)(((int)(object)lastId) + 1);
    }

    return lastId;
}

Вот мой взгляд на метод расширения: он будет работать нормально, если у ObjectContext, с которым я работаю, будет установлен нефильтрованный объект. В этом случае ObjectContext будет содержать все строки таблицы данных, и я получу точный результат. Но если набор сущностей является результатом фильтра запросов, метод вернет последний ключ сущности в отфильтрованном наборе сущностей, который не обязательно будет последним ключом в таблице данных. Поэтому я думаю, что метод расширения на самом деле не будет работать.

На данный момент очевидным решением является простое использование GUID в качестве ключа объекта. Таким образом, мне нужно только вызвать метод Guid.NewGuid(), чтобы установить свойство ID, прежде чем я добавлю новую сущность в свой ObjectContext.

Вот мой вопрос: есть ли простой способ получить последний первичный ключ в хранилище данных из EF4 (без необходимости создавать второй ObjectContext для этой цели)? Любая другая причина не выбрать легкий путь и просто использовать GUID? Спасибо за вашу помощь.

Ответы [ 4 ]

3 голосов
/ 22 марта 2010

В итоге я пошел с GUID.

  • Проблемы с размером / производительностью критично (или даже заметно) с SQL Compact, так как это локальная однопользовательская система. Это не так, как приложение будет управление бронированием авиабилетов система.

  • И, по крайней мере, на данный момент, есть кажется, нет никакого пути вокруг "нет Сгенерированные сервером ключи "ограничение стек SQL Compact / EF4. Если у кого-то есть умный взлом, я все еще открыт для него.

Это не значит, что я бы использовал тот же подход в SQL Server или SQL Express. У меня все еще есть определенные предпочтения для целочисленных ключей, и большие братья и сестры SQL Compact позволяют их в сочетании с EF4.

1 голос
/ 26 марта 2010

То, что я делал для SQL CE раньше, и я предполагаю, что у нас есть единственное приложение, обращающееся к базе данных, - это вычисление значения MAX при запуске и помещение его в статическую переменную. Теперь вы можете легко передавать последовательные значения и создавать код, который очень легко генерирует потокобезопасность.

1 голос
/ 26 марта 2010

Используйте Guid.Автоинкремент не поддерживается в Compact Framework с Entity Framework.

Кроме того, если вы когда-нибудь захотите создать приложение, использующее несколько источников данных, int PK распадется на вас очень и очень быстро.

  • С помощью Guid вы можете просто вызвать Guid.NewGuid (), чтобы получить новый ключ.
  • С помощью int вы должны попасть в базу данных, чтобы получить действительный ключ.

Если вы храните данные в нескольких базах данных, int PK вызовет конфликты.

0 голосов
/ 21 марта 2010

Одной из причин избегать Guids будет размер = потребление памяти и места на диске.

Вы также можете запросить метаданные SQL Compact следующим образом:

ВЫБРАТЬ AUTOINC_NEXT ИЗ ИНФОРМАЦИИ_SCHEMA.COLUMNS ГДЕ TABLE_NAME = 'Categories' И AUTOINC_NEXT НЕ НУЛЬ *

...