Cheerful CalfДобрый день,
Есть таблица ДокументыДвиженияОборудования, которая ссылается на ТипыДокументов (порт -> вышка, вышка -> поставщик, судно -> судно, вышка -> вышка, и т.д). Соответсвенно, в зависимости от типа source & destination у документов разные, при чем это не только разные адреса (freetext), а ссылки на конкретные объекты, у которых уже потом могут быть разные адреса (поставщик) или не быть адреса вообще (судно), и прочие другие аттрибуты.
Пока кроме как тупо делать в ДокументыДвиженияОборудования {..., VendorSourceId nullable, RigSourceId nullable, WellSourceId nullable, VessekSourceId nullable, VendorDestinationId nullable, RigDestinationId nullable, WellDestinationId nullable, VessekDestinationId nullable} ничего не придумывается. Хотя нет, придумалось это вынести в отдельную таблицу, но от того в каком месте бред - его менъше не становится. Кроме того, типов (соответсвенно соурсов и дестинейшинов) со временем может быть больше. Другая проблема - документ обязан иметь один и только один source / destination (как быть тут с not null и integrity)?

Заранее спасибо за советы.
Пока, не видно той проблемы, о которой Вы написали. Она скрыта за семантической проблемой. Что такое "вышка" или "судно". И что такое "поставщик"?

Пункты (подразделения, склады - используйте принятый термин):
1) Свои и чужие.
2) Статические и динамические.
Например, автопогрузчик - свое динамическое подразделение.
Не видно никакой проблемы перемещения материи между пунктами)

Cheerful CalfБредятина,

Вы предлагаете, вышки, судна, порты, терминалы - запихать в одну таблицу пункты (аля контрагенты) и использовать ключ (тип пункта) ?
Тогда уточню (сорри не упомянул сразу) - уже есть отдельные таблицы для каждого из типов пунктов (как для отдельных бизнесс объектов) и менять их крайне не рекомендовано...
Для меня это очевидно и без уточнения)) Более того, перемещением может заниматься, в частности, человек (умещается в кармане или не слишком тяжело). Очевидно же, что уже итак есть такой объект - Человек. Объект Пункт (назовем так) имеет:
1) группу вычисляемых характеристик (их значения определяются путем извлечения определенных характеристики по одной из возможных связей, например, Наименование может быть Петров Сергей Николаевич);
2) группу характеристик для "самодостаточного" экземпляра объекта (не имеющего ни одной связи) - при этом, значения вычисляемых характеристик, конечно, все равно вычисляются;
3) и каждый экземпляр может иметь связь с ОДНИМ экземпляром ОДНОГО из "базовых" объектов (а может и не иметь - для "самодостаточных").

Cheerful CalfБредятина,

Да. И как хранить это все? Если Петров Сергей Николаевич (из сущности HumanResources) учавствовал в двух перемещениях, в качестве пунктов? Вписать его АйДи (Int=55) в пункт? Как потом узнать что это айди human resours'a, а не терминала за айди 55 из таблицы Bases?
Вы только не обижайтесь, пожалуйста. То ли Вы не читаете сообщения, то ли не знакомы с основами БД(((
Документ: накладная на перемещение {Дата перемещения, ...}
Пункт {Наименование, ..., Наименование пункта, ...}
---
Документ: накладная на перемещение <-- Из/ Из которого (М:1) --- Пункт
Документ: накладная на перемещение <-- В/ В который (М:1) --- Пункт
Пункт --- Является/Является (1:1) --- Человек
Пункт --- Является/Является (1:1) --- Судно
Идентификаторы не могут никуда вписываться, так как принципиально не являются свойствами сущностей. Я теперь понимаю Ваши проблемы, ведь Вы не используете базы данных, а используете "реляционную технологию". Так нужно в самом первом сообщении сразу об этом говорить. Ведь раздел называется "Проектирование баз данных", а не "Проектирование реляционных баз данных"))

Cheerful CalfJeStone
И для каждого нового типа - по новой таблице? о.О


Бредятина,

Запахло EAV или я не понял?
Пункт --- Является/Является (1:1) --- Судно - этого точно не понял :(
Значит я угадал - не понимаете(( Обычная БД, обычные сущности, обычные связи. Причем, первые две Вы вроде бы поняли, а последние - вроде бы не поняли))

Cheerful CalfБредятинаа последние - вроде бы не понялиНу и кто из нас не читает сообщения? ;)
Я же так прямо и написал - этого точно не понял. Прошу мол, разжевать. Ну или хотябы подсказать как именно выполнать жевательные движения :)
Конечно, Вы))... Повторю, добавив в раздел сущностей еще две (думал, что это очевидно:

Документ: накладная на перемещение {Дата перемещения, ...}
Пункт {Наименование, ..., Наименование пункта, ...}
Человек {Фамилия, Имя, Отчество, ...}
Судно {Имя, ...}
---
Документ: накладная на перемещение <-- Из/ Из которого (М:1) --- Пункт
Документ: накладная на перемещение <-- В/ В который (М:1) --- Пункт
Пункт --- Является/Является (1:1) --- Человек
Пункт --- Является/Является (1:1) --- Судно

В данном фрагменте схемы БД четыре сущности (типа сущности) и четыре связи. Уточните, что Вам конкретно непонятно?) Я не могу просто поверить, что какие-то связи между типами сущностей понятны, а какие-то - непонятны((

softwarerCheerful CalfЯ же так прямо и написал - этого точно не понял. Прошу мол, разжевать.
ЧАЛ гонит про свой любимый мумпс. Если коротко, то его идентификатор - это указатель, который соответственно может указывать на произвольную область памяти.
Просто уже смешно из-за столь глубокого не понимания основ БД. Какой еще "мумпс"?? "Его идентификатор"?? "Указатель на область памяти"?? Что за бред, когда речь идет абсолютно на логическом уровне. Есть сущности и связи между ними, и нет (и даже теоретически не может быть) никаких указателей. И никаких проблем, в отличие от "реляционной технологии", бесконечные проблемы которой здесь и обсуждают перманентно))