1

Это продолжение по сравнению с earlier question Я разместил на EF4 сущности с SQL Compact. SQL Compact не позволяет создавать серверные ключи идентификации, поэтому мне остается создавать собственные ключи, поскольку объекты добавляются к ObjectContext. Мой первый выбор был бы целочисленный ключ, и предыдущий ответ связан с blog post, который показывает метод расширения, который использует оператор Max с выражением селектора, чтобы найти следующий доступный ключ:GUID или int entity key с SQL Compact/EF4?

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? Спасибо за вашу помощь.

+0

Подход, который вы показываете, не выглядит нитей безопасным вообще! Что остановить два потока от получения одинакового идентификатора? –

+0

Не проблема для меня - я использую только SQL CE для однопользовательских приложений, и я только создаю записи в одном потоке. Однако, если кто-то хочет создать многопоточную запись в SQL CE. –

ответ

3

Я в конечном итоге происходит с GUID.

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

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

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

0

Одной из причин избежать Гид будет размер = память и потребление пространства для хранения.

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

ВЫБОР AUTOINC_NEXT ОТ INFORMATION_SCHEMA.COLUMNS WHERE table_name = 'Категории' и AUTOINC_NEXT IS NOT NULL

+0

Как выполнить этот запрос с помощью EF4? –

1

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

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

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

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

1

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

+0

Я действительно рассматривал этот подход, и он хороший. Из-за своей простоты я закончил с GUID. –

Смежные вопросы