@sonmax

Добрый день!
Прошу совета по базам данных.
есть задача логистики деталей со склада на участок и обратно.
как правильно организовать таблицу для данной задачи?
пример:
есть деталь (Дт - 100 шт.), участок (Уч), склад (Ск)
процедура такая.
1. Уч - запрашивает со Ск, чтобы привезли Дт в полном количестве.
2. Ск - привозит на Уч только Дт -50шт. (это нормально)
3. Уч принимает в работу Дт -50шт. и в какой то момент времени изготавливает Дт -20шт.
4. Ск - видит изготовленные Дт -20шт. забирает их на склад и помечает как оприходовано.
5. Уч доделывает оставшиеся и повторяет пп1-4 пока все Дт не будут выданы на участок.

Пока я склоняюсь к мысли, чтобы в таблицу завести колонки для каждого этапа.
получится типа:
1. в колонке (Request) появляется 100шт. - это запрос на склад
3. в колонке (inWork) появляется 50шт. (Request=0 т.к. запрос выполнен)
и т.д.
насколько это правильная организация?
или есть другие варианты?
предложенный вариант мне тоже мало нравится, т.к. маршрут достаточно сложный
и колонок получается много, очень легко запутаться.

P.S.
Если что-то непонятно, я с удовольствием поясню, очень нужна помощь
Спасибо.

0

@phaggi

Я бы сделал так:
Если рассматривать за объект - партию деталей, а свойства этого объекта:
Порядковый номер партии (Ключ таблицы с автоинкрементом)
Кол-во деталей в партии (Положительное целое)
Местонахождение партии (Ссылка на таблицу, в которой объекты - места, т.е. Склад, Участок)
Признак оприходованности (булево)

Запись в такой таблице будет соответствовать партии деталей.
Первоначально в таблице будет 1 запись, 50 деталей, на складе, оприходованы.
Запросом к базе определяем, сколько оприходовано и на складе, меняем место на Участок. Это частично выполнен первый заказ на 100 деталей. В работе 50 деталей.
Следующим запросом к базе создаем партию 20 деталей, которая на Участке, не оприходована.
Затем меняем на ней параметр «место», это она уехала на склад.
Потом меняем признак «оприходовано» на true.
Теперь меняем «место» на «участок».

Теперь у нас на Участке 2 объекта числятся с признаком «оприходовано» true, на 20 и 50 деталей. Значит, в работе 70 деталей.
Следующий объект создаем, ещё сколько-то деталей на участке не оприходованных.
Дальше, мне кажется, всё понятно?

0

@Serg_o_Grey

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

На вскидку могу предложить следующую модель:
Деталь (Идентификатор, Наименование, ИдентификаторСостояния, [Описание, т.е. какие-нибудь характеристики детали, напр. вес, матириал изготовления, габариты и т.д.], ДатаВремяСозданияЗаписи, ДатаВремяУдаленияЗаписи)
СостояниеДетали (Идентификатор, [НаименованиеСостояния, например: активно, брак, в пути, потерян, списан, получен, выдан.. В общем нужно предусмотреть варианты], ДатаВремяСозданияЗаписи, ДатаВремяУдаленияЗаписи)
СкладХранение (ИдентификаторРядаМеста, ИдентификаторДетали, Количество, ДатаВремя, ИдентификаторСостояния, ИдентификаторКладовщика, ДатаВремяСозданияЗаписи, ДатаВремяУдаленияЗаписи)
РядМесто (Идентификатор, [СотояниеМеста, например: свободно, занято, влезет ещё, ликвидировано], Описание, ДатаВремяСозданияЗаписи, ДатаВремяУдаленияЗаписи)
Кладовщик (Идентификатор, Фамилия, Имя, Отчество, ДатаВремяСозданияЗаписи, ДатаВремяУдаленияЗаписи)
СкладУбытие (Идентификатор, ИдентификаторКладовщика, ИдентификаторПеревозчика, [ИдентификаторТранспортногоСредства], ИдентификаторДетали, ИдентификаторСостояния, ДатаВремяСозданияЗаписи, ДатаВремяУдаленияЗаписи)
СкладПрибытие (Идентификатор, ИдентификаторКладовщика, ИдентификаторПеревозчика, [ИдентификаторТранспортногоСредства], ИдентификаторДетали, ИдентификаторСостояния, ДатаВремяСозданияЗаписи, ДатаВремяУдаленияЗаписи)

Идея должна быть понятна из приведенного примера. Создаем для каждого класса сущностей свою таблицу. При изменении состояния сущности не удаляем запись физически, а просто ставим отметку в поле ДатаВремяУдаленияЗаписи и можно также добавить колонку ИдентификаторПричиныУдаления, что бы было проще восстановить картину событий, когда это понадобится.

Также для большей гибкости, например, в случае создания второго склада, можно вместо таблиц СкладХранение и Участок создать таблицы Объекты (Идентификаатор, НаименованиеОбъекта, [даты создания и удаления]) и ОбъектХранение (ИдентификааторОбъекта, ИдентификаторНахождения, ИдентификаторДетали, Количество, ДатаВремя, ИдентификаторСостояния, ИдентификаторОтветственногоЛица)

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

0

@Shamil1

Заведите таблицу для каждого типа первичного документа.
Так же, для ускорения работы можно завести таблицы-агрегаты (например, текущее количество деталей на объекте).

0