Идентификаторы на родительских и дочерних классах в NHibernate - PullRequest
0 голосов
/ 03 августа 2009

Работа над проектом, в котором у меня есть более или менее карт-бланш для изменения схемы базы данных и объектной модели (неплохая позиция. (C :) Предположим, у меня есть тривиальное дерево наследования, подобное:

class Parent
{
    public int ID { get; set; }
}

class Child : Parent
{
    // some fields
}

Лучше ли иметь схему базы данных, в которой дочерний идентификатор и родительский идентификатор совпадают (например, родительский первичный ключ равен IDENTITY (1,1), дочерний первичный ключ назначен и является внешним ключом NOT NULL для родительская таблица), или дочерняя таблица должна поддерживать свой собственный первичный ключ и сохранять ссылку на родительскую таблицу в другом поле? Какие соображения следует учитывать в этом случае? Каковы плюсы и минусы каждого подхода? NHibernate поддерживает оба, верно?

1 Ответ

1 голос
/ 03 августа 2009

Я бы дал ребенку собственный идентификатор. Это была бы бесполезная информация, но этот ущерб намного перевешивается тем фактом, что это будут легко узнаваемые отношения 1: 1, а не «Как, черт возьми, это работает? отношения.

И да, nHibernate может обрабатывать отношения один-к-одному.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...