powered by simpleCommunicator - 2.0.48     © 2025 Programmizd 02
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Структура базы для сложных производственных структур
11 сообщений из 36, страница 2 из 2
Структура базы для сложных производственных структур
    #40055718
Фотография crutchmaster
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
rick1177
Displayed_Name_Of_Equipment_N
VARCHAR(1024)
Связи много-много
Ничего не нормализировано.

Схема говнобазы.
rick1177
Что нужно, нужно обеспечить пользователям следующие возможности:
1. Вносить в базу данных список покупаемого нечто;

1. Нужна таблица с нечто.
2. Нужна таблица с покупаемым.
3. Нужна таблица с пользователями

rick1177
2. Обеспечить пользователю возможность "проектирования" сборного нечто из покупаемого;

4. Нужна таблица со сборками.
5. Нужна таблица с составом сборки.

rick1177
Обеспечить пользователю для нечто сборного и нечто покупаемого возможность в зависимости от объекта сделки назначать цену и хранить эту информацию, чтобы в любой момент времени можно было посмотреть на неё, собрать новое нечто и т.д.


6. Нужна таблица с ценами
...
Рейтинг: 0 / 0
Структура базы для сложных производственных структур
    #40055739
L_argo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
softwarer
L_argo
Сборные объекты должны быть привязаны к обезличенным позициям. А привязка обезличенной позиции к реальной меняется во времени.

Восхитительная терминология и не менее восхитительный бизнес-процесс. Теперь ради интереса опишем в нём следующий кейс:

- Кухарка №1 берёт килограмм муки завода №1 и лепит пирожок №1
- Кухарка №2 берёт килограмм муки завода №5 и лепит пирожок №2
- Кухарка №1 из той же муки лепит пирожок №3
- Кухарка №2 из той же муки лепит пирожок №4
- Кухарка №3 берёт килограмм муки завода №1, килограмм муки завода №5, сваливает их в одну миску и лепит из них пирожок №5.
Коллега, вы не поняли указанного кейса. Кухарка просто берет ХХкг обезличенной муки. А потом задним числом обезличенному кол-ву присваивается по ФИФО (вручную или автоматом) кол-во реального товара. И списывается в производство.
Это позволяет не менять рецепт каждый день.
...
Рейтинг: 0 / 0
Структура базы для сложных производственных структур
    #40055752
Stanislav P
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Таблица "Товары":
Код
Наименование
Тип (составной или конечный)

Таблица "Состав составного товара":
Код-составного-товара (код товара из "Товары)
Код-обычного-товара

Таблица "Клиенты":
Код
Наименование

Таблица "Контракт":
Код
Номер-контракта
Код-клиента

Таблица "Состав контракта"
Код-контракта
Код-клиента
Код-товара
Продажная-цена-товара

Этого вполне хватит под описанную задачу.
...
Рейтинг: 0 / 0
Структура базы для сложных производственных структур
    #40055828
s_ustinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dimitry Sibiryakov

s_ustinovНо это будет не древовидная таблица!

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

А потом, после реализации иерархии, мы обнаруживаем, что закупщикам нужна одна группировка, производственникам - другая, а продажникам - третья...
Я не знаю ни одной ситуации, когда "для сложных производственных структур" было достаточно одной иерархии.
И попытка сделать иерархию по товарным группам прямо в таблице товаров всегда оборачивается головной болью, так как потом приходится дополнительно сооружать "причудливую" конструкцию из костылей и велосипедов.
...
Рейтинг: 0 / 0
Структура базы для сложных производственных структур
    #40055831
s_ustinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
zeon11
s_ustinov
пропущено...

Дальше можно не читать.

Почитайте про историю развития баз данных, про иерархические базы, про COBOL и его работу с данными (https://en.wikipedia.org/wiki/COBOL#Aggregated_data) и т.д.

Как только начинаешь решать более - менее сложные задачи в области финансов, ERP и т.п., это все становится неудобно, и в целом для таких задач удобнее использовать РСУБД. Очень много написано статей на эту тему.


"Древовидная таблица" <> "иерархические базы",
и вариант предлагаемого решения для ТС предложен именно в парадигме РСУБД, так что не понятно, что Вы возбудились.
Если Вы не используете иерархические(древовидные) таблицы, то это совсем не значит, что другим их использовать запрещено.
Рыбу фугу не все повара готовят.

По поводу решения "более - менее сложных задач в области финансов, ERP и т.п." - не понятно, Ваш fencing prick относится к иерархическим БД или к иерархическим(древовидным) таблицам в в рамках РСУБД?

Я говорю о попытках "встроить" иерархию / классификацию прямо в таблицу товаров. Много раз сталкивался (1С - наше всё), и каждый раз подобное решение приносило сплошную головную боль.
То же относится и к справочнику клиентов, например. Бухгалтера делают "древовидную" структуру под свои потребности, а продажники потом плюются и требуют переделать.
...
Рейтинг: 0 / 0
Структура базы для сложных производственных структур
    #40055885
zeon11
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
s_ustinov
zeon11
пропущено...


"Древовидная таблица" <> "иерархические базы",
и вариант предлагаемого решения для ТС предложен именно в парадигме РСУБД, так что не понятно, что Вы возбудились.
Если Вы не используете иерархические(древовидные) таблицы, то это совсем не значит, что другим их использовать запрещено.
Рыбу фугу не все повара готовят.

По поводу решения "более - менее сложных задач в области финансов, ERP и т.п." - не понятно, Ваш fencing prick относится к иерархическим БД или к иерархическим(древовидным) таблицам в в рамках РСУБД?

Я говорю о попытках "встроить" иерархию / классификацию прямо в таблицу товаров. Много раз сталкивался (1С - наше всё), и каждый раз подобное решение приносило сплошную головную боль.
То же относится и к справочнику клиентов, например. Бухгалтера делают "древовидную" структуру под свои потребности, а продажники потом плюются и требуют переделать.


Свой первый миллион я заработал на 1С ;-), знаю, что это за болото. Иерархия там действительно ужасна, но я не об 1С.
Попробую прояснить за иерархические таблицы в своих проектах.
1. Так как пишу в одно рыло, то для меня создавать связку для справочника "ГРУППА-ЧЛЕНЫ_ГРУППЫ" из двух таблиц весьма накладно, это не только одна лишняя таблица, но и вся обвязка из триггеров, внешних ключей. Кроме того, для предоставления пользователю на форме нужно дополнительное место.
2. Часто бывает, что неожиданно требуется не двух-уровневая иерархия, а трёх-уровневая. Тогда снова за компьютер, кодировать.
3. Наследование. Да, да - наследование, и это очень круто. Если у вас иерархия, то автозаполнение свойствами нового подчиненного элемента не представляет никаких трудностей ни для программиста, ни для пользователя. Вы просто берёте все свойства из родительского узла, при необходимости корректируя нужные поля.
4. Каскадные изменения. Как часто я проклинал 1С, когда открывал в ней ветку справочника, а там несколько сотен элементов и в каждом надо было поменять однотипный параметр!!!. Не знаю, сейчас это как-то автоматизировали, или нет, но тогда это было невозможно. В своих справочниках для полей я могу поставить признак "КАСКАД", пользователю это поле представляется красным цветом, чтобы был осторожен. Но в одно действие в иерархическом справочнике пользователь может поменять несколько десятков тысяч записей.
5. Групповые операции. Тут всё понятно, зацепил мышкой корневую запись, или двинул куда надо, или обработал.
6. Компактность представления. Справочник на несколько тысяч позиций начинается всего с нескольких строчек.

Стоимость "дерева".
Под стоимостью понимаем ресурсы сервера, сети. Как ни странно, но иерархия более экономична, поскольку в дерево на клиенте выкачивается только необходимая информация из нужной ветки(веток) , а не вся справочная таблица.

Так что изначально все справочники я планирую как иерархические, а там пригодится-не пригодится.
...
Рейтинг: 0 / 0
Структура базы для сложных производственных структур
    #40055902
zeon11
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
s_ustinov

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


Сталкивался с такой бедой.
Решения было два, либо СУБКОНТО, либо выносить иерархию в отдельную таблицу.
Т.е. для продажников есть дерево ПРОДАЖНИК, где всего три поля Parent_ID, ChildCount, Ссылка на плоскую основную таблицу,
для Для Бухгалтеров такая-же таблица БУХГАЛТЕР. По обстоятельствам с основной таблицей джойнится либо одна, либо другая таблица.
...
Рейтинг: 0 / 0
Структура базы для сложных производственных структур
    #40057168
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
rick1177

Задача 1. Я проектирую БД.
Что нужно, нужно обеспечить пользователям следующие возможности:
1. Вносить в базу данных список покупаемого нечто;
2. Обеспечить пользователю возможность "проектирования" сборного нечто из покупаемого;
3. Обеспечить пользователю для нечто сборного и нечто покупаемого возможность в зависимости от объекта сделки назначать цену и хранить эту информацию, чтобы в любой момент времени можно было посмотреть на неё, собрать новое нечно и т.д.


Классное ТЗ!
Прямо вот садись, и пиши структуру БД!

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

УСПЕХОВ!
...
Рейтинг: 0 / 0
Структура базы для сложных производственных структур
    #40057188
L_argo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MasterZiv

Нормальное краткое ТЗ. Хоть и эскизно, но все понятно.
Обычное простое производство, н-р пекарни и цеха комплектации.

Тот кто в теме, поймет, о чем речь и что для этого нужно.
...
Рейтинг: 0 / 0
Структура базы для сложных производственных структур
    #40057229
s_ustinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
L_argo
MasterZiv

Нормальное краткое ТЗ. Хоть и эскизно, но все понятно.
Обычное простое производство , н-р пекарни и цеха комплектации.

Тот кто в теме, поймет, о чем речь и что для этого нужно.

А название темы "Структура базы для сложных производственных структур" не вызывает вопросов?
...
Рейтинг: 0 / 0
Структура базы для сложных производственных структур
    #40057230
L_argo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
s_ustinov
А название темы "Структура базы для сложных производственных структур" не вызывает вопросов?
Любая тема может вызвать вопросы.
...
Рейтинг: 0 / 0
11 сообщений из 36, страница 2 из 2
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Структура базы для сложных производственных структур
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]