skladЕсть сущность Склад/РабочееМесто, который содержит Детали. По бизнес-правилам, деталь в любой момент времени находится на одном из складов/рабочем месте (транспортировка не отслеживается).
Как лучше сделать, сущности Деталь присвоить атрибут Склад, или создать отдельную таблицу Склад/Деталь, где хранить какой склад содержит какую деталь ? Если вопрос о подчиненности таблиц, то напрашивается такое: Склад - master, Деталь - detail :). Дело, конечно, не в названии сущностей, а в том на складе размещается множество деталей. Отсюда классическое один-ко-многим.

nosov Senya_LЕсли вопрос о подчиненности таблиц, то напрашивается такое: Склад - master, Деталь - detail ключевой обЪект в такой БД -- это сама деталь, узел, агрегат ...
склад--ряд--полка--палета и т.д. -- это просто координата места временного пребывания детали до ее отправки заказчику или в сборочный цех. И какой напрашивается вывод? предлагаете многие-ко-многим, что ли? Не стоит возводить "Деталь" во главу угла, что называется. ИМХО, первично и главное в реляционной модели то, какие отношения существуют между сущностями.

Shtockглавное понимать,что не склад место детали,а паллета, полка или прочяя сущность более мелкого уровня. Ничто не мешает сделать таблицу полок, паллет и т.п. и сделать ее подчиненной к таблице склады. Таблица Деталей становиться подчиненной к таблице Полок. Чем такой вариант плох?

chAlxПо-моему, автор и так знает, какие есть варианты, причём оба подходящие. Так что остаётся рассмотреть вопрос реализации (типа "эти данные постоянно читаются, а эти меняются только при приёмке, так что разделим таблицы, чтобы версионная БД копила меньше мусора"). Если с реализацией вопросов нет, то надо делать, как проще.

Senya_L chAlxПо-моему, автор и так знает, какие есть варианты, причём оба подходящие. Так что остаётся рассмотреть вопрос реализации (типа "эти данные постоянно читаются, а эти меняются только при приёмке, так что разделим таблицы, чтобы версионная БД копила меньше мусора"). Если с реализацией вопросов нет, то надо делать, как проще.
А я про то же

nosov Senya_lНе стоит возводить "Деталь" во главу угла,позвольте с Вами не согласитЬся...
ибо не было бы деталей и не нужны тогда : склады, ряды, полки, палеты и т.п.
а также кладовщики, электрокарщики и т.д. Принимаю молчание по поводу
Япредлагаете многие-ко-многим, что ли? за согласие и иду на Вы :)
Ну не нравится мне этот тип связи и все тут. Особенно его использование где надо и не надо. Ведь ясно же, что деталь не может быть одновременно на двух складах. ИМХО, таблица связей Склад-Деталь открывает путь именно к такой ситуации. Иногда и UNIQUE-ограничение не поможет.

ShtockТак моя схема и не возводит деталь во главу угла. ПРосто я вообще не вижу разговора про движение деталей. А именно там и появляется конкретное место нахождения детали (причем на паллете, полке или чем-нибудь другим). Тогда покажите схему, не томите :). Абстракция нагоняет тоску