Идентификаторы ромбовидной связи между таблицами
У меня есть четыре таблицы (A, B, C, D), где A является родительским элементом отношений один-ко-многим с B и C. C и D являются родительскими элементами отношения один-ко-многим с таблицей D. Концептуально, первичные ключи этих таблицы могут быть:
- A: Помощь
- B: Aid, bnum (с внешним ключом к A)
- C: помощь, cnum (с внешним ключом к A)
- D: Aid, bnum, cnum (с внешними ключами для B и C)
Если столбцы 'num' автоматически увеличиваются на основе каждого родительского идентификатора в отношении, а не для каждой записи. Я использовал этот подход в предыдущем приложении, и это не было проблемой, поскольку создание записей B и C выполнялось последовательным процессом путем генерации нового значения «num» с помощью запроса «select max ()». Мне никогда не нравился такой подход, но он сделал свою работу.
В конкретном случае, над которым я сейчас работаю, записи в таблицах A и B вводятся пользователями, поэтому автоматическое создание идентификаторов не является проблемой. В случае таблиц C и D записи в этих таблицах создаются несколькими параллельными пакетными процессами, поэтому их идентификаторы нужно будет каким-то образом сгенерировать. Предыдущий метод, который я перечислил, не подходит для состояния гонки.
Обратите внимание, что это для базы данных Oracle, поэтому я буду использовать последовательности, а не столбцы с автоматическим приращением.
Учитывая приведенные выше ограничения, как бы вы спроектировали таблицы для представления A, B, C и D, чтобы отношения между объектами выполнялись должным образом, И код приложения не требовался бы для генерации каких-либо идентификаторов?
Да, мне не совсем понятно, в чем проблема.
Область этого приложения ориентирована на исследования, поэтому для объяснения фактических терминов потребуется несколько страниц документации, поэтому я использовал буквы.
Я попробую придумать параллельную задачу для использования в качестве примера.
Ответы 2
Последовательности или Autonumbers всегда должны генерироваться системой базы данных, а не приложением. Для MSSQL это можно сделать с помощью хранимой процедуры и возврата из хранимой процедуры «select @@ identity», чтобы дать приложению идентификатор вставленной строки.
Последовательности отлично подходят для первичных ключей imo, но есть лагеря, которые поклоняются богу «естественных ключей».
Значение данных, хранящихся в таблице, и значение отношения важны для полного ответа на ваш вопрос, но отношения могут допускать каскадные удаления.
Лично я бы сделал последовательности первичных ключей в каждой таблице и допустил бы внешние ключи, которые не являются частью первичного ключа. Вы должны определить свои таблицы по основным объектам (например, сотруднику, товарам, магазину), а затем отношения между ними будут складываться из комбинаций. Таким образом, у сотрудника в магазине будет таблица «storeemployee», а первичный ключ будет пустой. , storeid без определенной последовательности. Обычно я думаю об этом с точки зрения вещей как объектов (которые всегда имеют последовательности для первичных ключей) и отношений между объектами (с использованием идентификаторов других таблиц в качестве комбинированных первичных ключей).
Надеюсь, это поможет!
Обновлено: я должен добавить, что это прекрасно учитывает ромбовидные отношения. Подумайте о «магазинах» и «сотрудниках». Один стол может быть для сотрудников магазина, а другой - для магазина. Оба будут идентифицировать магазин и сотрудника, но имеют в виду совершенно разные вещи. Один - это, возможно, отработанные часы, а другой - продажи.
Если я правильно понимаю, у вас было решение, в котором вы могли
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
Не могли бы вы спросить это, но будьте более загадочными? Попробуйте заменить все свои слова буквами, а затем поставить легенду. </ dickish sarcasm> Неужели ты, A, B, C, D ?? Какие у вас столы - что в них? Что представляют собой внешние ключи? Вы получите лучший ответ, задав более четкий вопрос.