Наследование и модель Id

Question

У меня есть класс Person в подсистеме Contacts. С другой стороны, в подсистеме CRM у меня есть понятие Customer.

В дизайне базы данных, я хочу создать связь между этими понятиями. Есть несколько возможных способов:

1. Каждый клиент является человек, таким образом, клиент должен наследоваться от человека и клиент умирает, как только его лицо удаляется (Состав). В этом случае, мы создаем one-to-one отношений между Id столбцами Customers таблицы и People таблицей, и мы делаем Id столбца таблицы People поле идентичности, но мы явно вставить scope_identity() в Customers таблицы.
2. Каждый клиент имеет человек, поэтому у клиента и человека есть свой жизненный цикл (Агрегация) и он может выжить без другого. В этом случае таблица Customers должна иметь внешний ключ для таблицы People. Плохая точка здесь в том, что у каждого Person может быть много Customers, что кажется странным для меня.

Какой дизайн предлагается в качестве наилучшей практики? Мне нужны твердые объективные ответы. Спасибо.

Answer 1

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

Если Person является базовым классом о Клиенте, то поле идентификатора является таким же, и вы не указываете его в классе Customer, потому что он наследует Person.

В первом случае (Person и клиентов с FK) у вас есть:

class Person { 
    private String id; 
    ... and so on 
    ... put here get and set property (as getId()/setId() and so on) 
} 

class Customer { 
    private String id; // this is different by id of Person class 
    private Person person; 
    ... and so on 
    ... put here get and set property (as getId()/setId() and so on) 
} 

Во втором случае (Заказчик расширяет Person) у вас есть:

class Person { 
    private String id; 
    ... and so on 
    ... put here get and set property (as getId()/setId() and so on) 
} 

class Customer extends Person { 
    ... other properties about Customer 
    ... put here get and set property 
} 

Answer 2

Есть разные случаи, когда вы может или не может дать каждой таблице собственный идентификатор.

В вашем случае было бы лучше, если бы у таблицы клиентов был свой собственный идентификатор.

Пример: Собственный идентификатор во многих отношениях, определяющих таблицу, является избыточным, когда он не имеет дополнительного столбца, связанного отдельно от таблиц, которые он соединяет. Рассмотрим отношение Teacher и Student. У них много отношения. Если есть таблица с именем TeacherStudentRelation, имеющая только внешний ключ для Teacher и Student таблица, то не нужно никаких дополнительных полей OwnId.

Но в вашем случае таблица Customer наверняка имела бы дополнительную информацию, связанную, например, balance, purchaseList или что-то в этом роде. И очень вероятно, что вы найдете в таблице Customer для некоторых данных. Здесь OwnId таблицы клиентов позволит вам индексировать эту таблицу.

Коротко говоря, дайте Customer таблице собственного Идентификатора.