2009-08-14 2 views
2

Предположим, что я хочу, чтобы записи в таблице Regions имели тип, например. город, страна и т. д. Каков приемлемый способ хранения этого типа, предполагая, что я буду использовать O/RM (NHibernate в моем случае)? Я вижу два варианта:Перечисления в базе данных и O/RM

  • Have перечисления в # BUSSINES слое C с типами и хранить тип как tinyint в таблице.
  • Имейте таблицу поиска RegionTypes с идентификаторами типа (строки или целые числа) и ссылайтесь на них в таблице Regions.

Второй подход кажется более разумным с точки зрения базы данных, так как у меня есть ограничения внешнего ключа, плюс я могу получить дополнительные данные о типах областей, например. город является дочерним типом для страны (и поскольку я использую пространственные функции SQL Server 2008, мне действительно нужна эта информация для пространственных манипуляций). Однако, смотря с точки зрения C#, я в основном должен иметь объект RegionType и загружать его из базы данных каждый раз, когда я хочу присвоить его региону (поскольку я понимаю, что NHibernate не позволит мне создавать тип перечисление, если я сохраню его в таблице поиска). Это немного утомительно для такой простой задачи, зная, что типы регионов в основном фиксированы и вряд ли изменятся.

Как насчет других типов, таких как DayOfWeek, которые вряд ли когда-либо изменятся или будут иметь дополнительные свойства, должны ли они иметь таблицы поиска и сущности?

ответ

2

Общее правило заключается в использовании Enum сек, если вы уверены, что множество значений не будет изменено пользователем . В противном случае лучше использовать таблицу поиска.

0

Я обычно использую последний вариант, однако я создам общий тип настройки, в котором элементы нескольких типов могут храниться в одной таблице, так что я не получаю таблицы из 15 типов. Основы являются чем-то вроде этого

Types 
    TypeID int, 
    Name varchar(20), 
    Description varchar(100) 

Type_Items 
    ItemID int, 
    TypeID int -> Types.TypeID, 
    Name varchar(20), 
    Description varchar(100), 
    Value varchar(100) 
+0

Это будет хорошая и достоверная система поиска/ссылки, но полностью недействительна в отношении реляционной целостности базы данных. –

+0

@Philip: Как так? –

+0

Вы не смогли бы установить ограничение внешнего ключа «в» таблицу поиска, если только полный первичный ключ (тип + идентификатор) не присутствовал в * родительской и дочерней таблице *. РСУБД очень хороши в обеспечении реляционной целостности, и я не хочу терять эти функциональные возможности. –

1

Одной из причин для использования справочных таблиц является совместное использование случай отображения возможных значений в меню или что-то. Легко запросить таблицу поиска, но менее легко, если перечисление жестко закодировано в типе или ограничении базы данных или в перечислении C#.