Предположим, что я хочу, чтобы записи в таблице Regions
имели тип, например. город, страна и т. д. Каков приемлемый способ хранения этого типа, предполагая, что я буду использовать O/RM (NHibernate в моем случае)? Я вижу два варианта:Перечисления в базе данных и O/RM
- Have перечисления в # BUSSINES слое C с типами и хранить тип как
tinyint
в таблице. - Имейте таблицу поиска
RegionTypes
с идентификаторами типа (строки или целые числа) и ссылайтесь на них в таблицеRegions
.
Второй подход кажется более разумным с точки зрения базы данных, так как у меня есть ограничения внешнего ключа, плюс я могу получить дополнительные данные о типах областей, например. город является дочерним типом для страны (и поскольку я использую пространственные функции SQL Server 2008, мне действительно нужна эта информация для пространственных манипуляций). Однако, смотря с точки зрения C#, я в основном должен иметь объект RegionType
и загружать его из базы данных каждый раз, когда я хочу присвоить его региону (поскольку я понимаю, что NHibernate не позволит мне создавать тип перечисление, если я сохраню его в таблице поиска). Это немного утомительно для такой простой задачи, зная, что типы регионов в основном фиксированы и вряд ли изменятся.
Как насчет других типов, таких как DayOfWeek
, которые вряд ли когда-либо изменятся или будут иметь дополнительные свойства, должны ли они иметь таблицы поиска и сущности?
Это будет хорошая и достоверная система поиска/ссылки, но полностью недействительна в отношении реляционной целостности базы данных. –
@Philip: Как так? –
Вы не смогли бы установить ограничение внешнего ключа «в» таблицу поиска, если только полный первичный ключ (тип + идентификатор) не присутствовал в * родительской и дочерней таблице *. РСУБД очень хороши в обеспечении реляционной целостности, и я не хочу терять эти функциональные возможности. –