Идентификаторы в бриллиантовой взаимосвязи между таблицами

У меня есть четыре таблицы (A, B, C, D), где A является родителем отношений один-ко-многим с B и C. C и D являются родителями отношения один-ко-многим с таблицей D. Концептуально, первичные ключи этих Таблицы могут быть:

  • A: Помощь
  • B: Aid, bnum (с внешним ключом к A)
  • C: Aid, cnum (с внешним ключом к A)
  • D: Помощь, bnum, cnum (с внешними ключами к B и C)

Где столбцы 'num' автоматически увеличиваются на основе каждого родительского идентификатора в отношении, а не на каждой записи. Я использовал этот подход в предыдущем приложении, и это не было проблемой, так как создание записей B и C было выполнено последовательным процессом путем создания нового значения 'num' с помощью запроса 'select max ()'. Я никогда не был действительно удовлетворен подходом, но это сделало работу.

Для конкретного случая, над которым я сейчас работаю, записи в таблицах A и B вводятся пользователями, поэтому автоматическая генерация идентификаторов не является проблемой. В случае таблиц C и D записи в этих таблицах генерируются несколькими параллельными пакетными процессами, поэтому их идентификаторы должны быть сгенерированы каким-либо образом. Предыдущий метод, который я перечислил, не работает в зависимости от состояния гонки.

Обратите внимание, что это для базы данных Oracle, поэтому я буду использовать последовательности, а не столбцы с автоинкрементом.

Учитывая вышеприведенные ограничения, как бы вы разработали таблицы для представления A, B, C и D так, чтобы отношения между сущностями были должным образом применены И код приложения не потребовался для генерации каких-либо идентификаторов?

10.12.2008 19:41:22
Не могли бы вы спросить, но быть более загадочным? Попробуйте заменить все ваши слова буквами, а затем поставить легенду. </ dickish сарказм> Действительно ты, A, B, C, D ?? Каковы ваши таблицы - что в них? Что представляют собой внешние ключи? Вы получите лучший ответ с более ясным вопросом.
Kieveli 10.12.2008 20:17:37
Да, мне не совсем ясно, в чем проблема.
David Aldridge 10.12.2008 20:24:41
Область этого приложения ориентирована на исследования, и поэтому для объяснения реальных терминов потребуется несколько страниц, поэтому я использовал буквы.
Mark Roddy 10.12.2008 21:17:38
Я постараюсь придумать параллельную проблему для использования в качестве примера.
Mark Roddy 10.12.2008 21:22:55
2 ОТВЕТА
РЕШЕНИЕ

Если я правильно понимаю, у вас было решение, где вы можете иметь

Table A
-------
100
101
102

Table B
-------
100 1
100 2
101 1

Table C
-------
100 1
100 2
101 1


Table D
-------
100 1 1
100 2 1
100 1 2
101 1 1

и т.п.

Теперь, имеет ли значение, являются ли значения 'num' маленькими и в последовательности без пропусков? Если нет, то просто используйте последовательности для них тоже. Таким образом, вы можете получить

Table B
-------
100 29125
100 29138
101 29130

Table D
-------
100 29125 401907
100 29138 404911
101 29130 803888

Я бы использовал отдельные последовательности для bnum и cnum. При выборе вы можете (при желании) использовать что-то вроде

SELECT AID, 
      RANK(BNUM) OVER (PARTITION BY AID ORDER BY BNUM) bnum_seq,
      RANK(CNUM) OVER (PARTITION BY AID ORDER BY CNUM) cnum_seq
0
10.12.2008 21:52:07

Последовательности или Autonumbers должны всегда генерироваться системой базы данных, а не приложением. Для MSSQL это можно сделать с помощью хранимой процедуры и возврата «select @@ identity» из хранимой процедуры, чтобы дать приложению идентификатор вставленной строки.

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

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

Лично я бы сделал последовательности первичных ключей в каждой таблице и учел бы внешние ключи, которые не являются частью первичного ключа. Вы определяете свои таблицы по основным объектам (таким как сотрудник, товар, магазин), и тогда отношения между ними будут состоять из комбинаций. Таким образом, у сотрудника в магазине будет таблица «storeemployee», и первичный ключ будет empid. , storeid без определенной последовательности. Обычно я думаю об этом с точки зрения вещей как объектов (которые всегда имеют последовательности для первичных ключей) и отношений между объектами (с использованием идентификаторов других таблиц в качестве комбинированных первичных ключей).

Надеюсь, это поможет!

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

0
10.12.2008 20:28:21