Учета данных hierarchyid в курсе

Я в середине рефакторинга старой структуры базы данных страны / региона / местоположения в иерархическую таблицу.

Я собираюсь использовать первичный ключ новой таблицы и столбец ParentID с собственной ссылкой (на первичный ключ) в качестве основы для столбца hierarchyid.

Поэтому моя таблица выглядит так:

PK Name ParentID HierarchyID

1 World NULL /

2 Великобритания 1 / 1 /

3 Уиган 2 /1/2

Мой вопрос: какие методы были реализованы другими для поддержания столбцов hierarchyid в актуальном состоянии при создании записи или изменении родительского элемента записи?

Примечание; я использую LINQtoSQL (я использую вычисляемый hierarchyid.Столбец ToString (), чтобы показать родословную в коде, плюс хранимые процедуры, чтобы дать мне преимущество производительности запросов hierarchyid).

Для управления вставкой / обновлением:

Я рассматривал возможность переопределения процедур insert / update в LINQtoSQL для моей новой таблицы.

Я рассматривал возможность использования хранимых процедур для управления обновлением / вставкой новых записей.

Я рассматривал рекурсивный триггер после insert / update для выполнения обновления на основе ParentID.

Однако я еще не принял решения, какой курс избрать!

Кто-нибудь использовал какой-либо из этих методов для управления hierarchyids? Есть ли лучшие методы, которые я не рассматривал, или я упускаю что-то действительно очевидное!!?

1 2
sql-server-2008 linq-to-sql hierarchical-data

1 ответ:

Недавно я сделал аналогичный проект, в котором я использовал хранимые процедуры для управления идентификаторами. LINQ хорош, если вы делаете несколько простых запросов, но он создает трудности при отладке и обслуживании модели данных.

Хорошая часть использования хранимой процедуры заключается в том, что она абстрагирует управление идентификаторами от уровня приложения, так что разработчику не нужно понимать базовую модель(ы) базы данных. Аналогично с плохой стороны, он абстрагирует управление id от уровень приложений, так что разработчик не может понять базовую модель(ы) базы данных без перехода к базе данных и просмотра сохраненного proc.

Использование триггера базы данных, вероятно, было бы лучшим решением, но я решил не идти с этим просто потому, что это добавило бы еще один уровень абстракции. Это происходит потому, что он еще больше запутывает истинный процесс обработки данных, оставляя другое место для поиска кого-то, кто, возможно, пытается выяснить, как все это работает.

Суть в том, что вы должны обеспечить свою ссылочную целостность таким образом, чтобы она была согласована в вашей системе (или, по крайней мере, в вашем проекте).

2