Проектирование базы данных: хранение первичного ключа в виде отдельного поля в той же таблице

Question

У меня есть таблица, которая должна ссылаться на другую запись, но той же таблицы. Вот пример:

Customer
********
ID
ManagerID (the ID of another customer)
...

У меня плохое предчувствие. Моя другая идея состояла в том, чтобы просто иметь отдельную таблицу, в которой просто хранятся отношения.

CustomerRelationship
***************
ID
CustomerID
ManagerID

Я чувствую, что, может быть, слишком усложняю такую ​​тривиальную вещь, однако, я хотел бы получить некоторую идею о наилучшем подходе для этого конкретного сценария?

Спасибо.

Answer 1

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

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

Answer 2

Нет ничего плохого в первом подходе, фактически Oracle включил расширение «CONNECT BY» для SQL начиная с версии 6, которая предназначена для непосредственной поддержки этого типа иерархической структуры (и, возможно, делает Oracle достойным рассмотрения как базы данных, если вы собираетесь делать много этого).

Вам понадобятся самостоятельные объединения в базах данных, в которых нет чего-то аналогичного, но это также прекрасно и стандартное решение.

Answer 3

Вы можете использовать первый подход. См. Также Использование самостоятельных соединений

Answer 4

Может ли Заказчик иметь несколько менеджеров? Если это так, то вам нужна отдельная таблица. В противном случае подойдет только одна таблица.

Answer 5

Почему у вас "плохое предчувствие" по этому поводу? Для таблицы вполне допустимо ссылаться на собственный первичный ключ. Введение вторичной таблицы только увеличивает сложность ваших запросов и негативно влияет на производительность.

Answer 6

Единственная причина, по которой я бы порекомендовал избегать таких самоссылающихся таблиц, состоит в том, что в SQL Server есть несколько мест, где существуют ограничения для самоссылающихся таблиц.

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

Но кроме этого - сам по себе дизайн является надежным и абсолютно действительным - дерзайте! Я всегда хотел, чтобы все было как можно проще (но не проще).

Марк

Answer 7

Следуйте здесь принципу KISS: будь проще, (глупо | глупо | стад | [любой эпитет, начинающийся с S, ты предпочитаешь]). Придерживайтесь одного стола, если у вас нет причин нуждаться в большем.

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

Answer 8

Как программист мне нравится первый подход. Мне нравится иметь меньше столов. Здесь мы даже не говорим о нормализации и зачем нам больше таблиц? Это только я.