powered by simpleCommunicator - 2.0.46     © 2025 Programmizd 02
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Структура базы для сложных производственных структур
25 сообщений из 36, страница 1 из 2
Структура базы для сложных производственных структур
    #40054626
rick1177
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Добрый день.
Коллеги, я тут совсем новенький и MySql знаний у меня маловато, а также опыт только начинается.
На этом чудесном Форуме я раньше лишь читал ответы на вопросы, но ни разу не задавал вопросов.

Если позволите, то вот моя задачка.

У предприятия есть покупные позиции, которые это предприятие продаёт (таблица 1).
Также предприятие из этих покупных позиций делает сборные объекты и продаёт (таблица 2).
(по хватит).

Для каждого заказчика цена разная и спецификация комплектуется и из таблицы 2 и из таблицы 1.

Требуется сформировать таблицу, где можно будет указывать позиции из т.1 и т.2, заказчика и цену для него.

Вопрос, собственно, как это будет выглядеть в базе и как лучше это организовать?

Сейчас таблица 1 выглядит так:
Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
CREATE TABLE IF NOT EXISTS `Prominform_Sales_DB`.`purchased_Мaterials_And_Equipment` (
  `ID` INT UNSIGNED NOT NULL AUTO_INCREMENT,
  `Equipment_Manufacturer_ID` INT NOT NULL,
  `Equipment_Brand` VARCHAR(1024) NOT NULL,
  `Name_Of_Equipment` VARCHAR(1024) NOT NULL,
  `Equipment_Code` VARCHAR(1024) NULL,
  `Description` VARCHAR(1024) NULL,
  `Software` VARCHAR(1024) NULL,
  `Acquisition_Currency_ID` INT NOT NULL,
  `VAT` VARCHAR(45) NOT NULL,
  `Displayed_Name_Of_Equipment_1` VARCHAR(1024) NULL,
  `Displayed_Name_Of_Equipment_2` VARCHAR(1024) NULL,
  `Displayed_Name_Of_Equipment_3` VARCHAR(1024) NULL,
  `Displayed_Name_Of_Equipment_4` VARCHAR(1024) NULL,
  `Displayed_Name_Of_Equipment_5` VARCHAR(1024) NULL,
  PRIMARY KEY (`ID`, `Acquisition_Currency_ID`, `Equipment_Manufacturer_ID`),
  UNIQUE INDEX `ID_UNIQUE` (`ID` ASC) INVISIBLE,
  INDEX `fk_purchased_Мaterials_And_Equipment_equipment_Manufacture_idx1` (`Equipment_Manufacturer_ID` ASC) VISIBLE,
  INDEX `fk_purchased_Мaterials_And_Equipment_deal_Currency1_idx` (`Acquisition_Currency_ID` ASC) VISIBLE,
  CONSTRAINT `fk_purchased_Мaterials_And_Equipment_equipment_Manufacturer1`
    FOREIGN KEY (`Equipment_Manufacturer_ID`)
    REFERENCES `Prominform_Sales_DB`.`equipment_Manufacturer` (`ID`)
    ON DELETE NO ACTION
    ON UPDATE NO ACTION,
  CONSTRAINT `fk_purchased_Мaterials_And_Equipment_deal_Currency1`
    FOREIGN KEY (`Acquisition_Currency_ID`)
    REFERENCES `Prominform_Sales_DB`.`deal_Currency` (`ID`)
    ON DELETE NO ACTION
    ON UPDATE NO ACTION)
ENGINE = InnoDB



Соответственно, таблица 2:
Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
CREATE TABLE IF NOT EXISTS `Prominform_Sales_DB`.`prefabricated_Equipment` (
  `ID` INT UNSIGNED NOT NULL AUTO_INCREMENT,
  `Name_Of_Equipment` VARCHAR(1024) NOT NULL,
  `used_Purchased_Мaterials_And_Equipment_ID` INT UNSIGNED NOT NULL,
  `Displayed_Name_Of_Equipment_1` VARCHAR(1024) NULL,
  `Displayed_Name_Of_Equipment_2` VARCHAR(1024) NULL,
  `Displayed_Name_Of_Equipment_3` VARCHAR(1024) NULL,
  `Displayed_Name_Of_Equipment_4` VARCHAR(1024) NULL,
  `Displayed_Name_Of_Equipment_5` VARCHAR(1024) NULL,
  `Equipment_Manufacturer` VARCHAR(1024) NOT NULL,
  `Description` VARCHAR(1024) NULL,
  `Other_Сosts` VARCHAR(1024) NULL,
  PRIMARY KEY (`ID`, `used_Purchased_Мaterials_And_Equipment_ID`),
  UNIQUE INDEX `ID_UNIQUE` (`ID` ASC) VISIBLE,
  INDEX `fk_prefabricated_Equipment_purchased_Мaterials_And_Equipme_idx` (`used_Purchased_Мaterials_And_Equipment_ID` ASC) VISIBLE,
  CONSTRAINT `fk_prefabricated_Equipment_purchased_Мaterials_And_Equipment1`
    FOREIGN KEY (`used_Purchased_Мaterials_And_Equipment_ID`)
    REFERENCES `Prominform_Sales_DB`.`purchased_Мaterials_And_Equipment` (`ID`)
    ON DELETE NO ACTION
    ON UPDATE NO ACTION)
ENGINE = InnoDB



Дополнительные таблички (1):
Код: plsql
1.
2.
3.
4.
5.
6.
CREATE TABLE IF NOT EXISTS `Prominform_Sales_DB`.`equipment_Manufacturer` (
  `ID` INT UNSIGNED NOT NULL AUTO_INCREMENT,
  `Equipment_Manufacturer` VARCHAR(1024) NOT NULL,
  PRIMARY KEY (`ID`),
  UNIQUE INDEX `ID_UNIQUE` (`ID` ASC) VISIBLE)
ENGINE = InnoDB



Дополнительные таблички (2):
Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
CREATE TABLE IF NOT EXISTS `Prominform_Sales_DB`.`deal_Currency` (
  `ID` INT UNSIGNED NOT NULL AUTO_INCREMENT,
  `Name` VARCHAR(45) NOT NULL,
  `Currency_Symbols` VARCHAR(3) NOT NULL,
  PRIMARY KEY (`ID`),
  UNIQUE INDEX `ID_UNIQUE` (`ID` ASC) VISIBLE,
  UNIQUE INDEX `Name_UNIQUE` (`Name` ASC) VISIBLE,
  UNIQUE INDEX `Currency_Symbols_UNIQUE` (`Currency_Symbols` ASC) VISIBLE)
ENGINE = InnoDB



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

Не очень понятна задача - нужно спроектировать БД или по готовой БД написать запрос?
Если первое, то нужна постановка задачи и описание предметной области.
Если второе, то нужно конкретнее описать желаемый запрос, желательно с примером входных и выходных данных.
...
Рейтинг: 0 / 0
Структура базы для сложных производственных структур
    #40054654
rick1177
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
miksoft,

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

Достаточно?
Может быть можно конкретизировать вопросы?

Модератор: Тема перенесена из форума "MySQL".
...
Рейтинг: 0 / 0
Структура базы для сложных производственных структур
    #40054706
Фотография vmag
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
rick1177,

Задача элементарная...
Вот вы заходите в супермаркет и видите на полках еду...
Консервы, хлеб, макароны и т.д. купили за одну цену и выложили на полки с другой ценой...
Это ваша первая табличка товар (ид товара, наименование, цена закупки, цена продажи)...
Вы подходите к кассе и видите те же продукты, но уже в наборах, например в пакете с бантиком пачка гречки, пачка сахара и банка тушенки...
Это надстройка над первой таблицей, состоящая из двух таблиц:
1. Набор (ид набора, название набора, цена набора)
2. Состав набора (ид набора, ид товара, количество)

Вы можете купить как по отдельности гречку, сахар и тушенку, причем в разных количествах, так и наборами...

Но мне лично кажется, что вам нужен типичный стол заказов - те же я..а, только вид сбоку, где заказы не фиксированы как наборы, а формируются налету, в заказе может быть одна или несколько позиций...
Заказ - это шапка документа: чек, счет, акт и т.д. (кто, кому, дата, номер)
Состав заказа - это строки документа (ид товара, количество, цена продажи)
...
Рейтинг: 0 / 0
Структура базы для сложных производственных структур
    #40054713
rick1177
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
vmag, Погодите! Это же не так!
Здесь Важная часть пропущена. продажа каждому отдельному клиенту осуществляется по разной цене. И не хочется совмещать в одной таблице цену реализации и наименование товара. Ведь клиентов очень много.
...
Рейтинг: 0 / 0
Структура базы для сложных производственных структур
    #40054715
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
rick1177И не хочется совмещать в одной таблице цену реализации и наименование товара.

Не хочется - не совмещай. Поставь ссылку на справочник товаров. Третья нормальная форма
одобряет.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Структура базы для сложных производственных структур
    #40054721
rick1177
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Dimitry Sibiryakov, т.е. получается, что будет ещё 2 таблицы, в каждой из которых будет ссылка на позицию в таблице 1 и 2 ... а нельзя сделать всё в одну таблицу?
...
Рейтинг: 0 / 0
Структура базы для сложных производственных структур
    #40054739
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Можно, но препод не примет.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Структура базы для сложных производственных структур
    #40054743
Фотография vmag
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
rick1177
vmag, Погодите! Это же не так!
Здесь Важная часть пропущена. продажа каждому отдельному клиенту осуществляется по разной цене. И не хочется совмещать в одной таблице цену реализации и наименование товара. Ведь клиентов очень много.


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

rick1177
т.е. получается, что будет ещё 2 таблицы, в каждой из которых будет ссылка на позицию в таблице 1 и 2 ... а нельзя сделать всё в одну таблицу?


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

И на будущее - попробуйте прежде чем отвечать на чужой пост, прочитайте его ровно 5 раз в слух
...
Рейтинг: 0 / 0
Структура базы для сложных производственных структур
    #40054786
rick1177
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
vmag, я, честно говоря, не понимаю, в чём причина столь злобного клёкота на меня.
Я, не понимая, просто уточняю, дополнительно выясняю, учусь.
Ну если Вы не готовы помогать и разъяснять, дк пройдите мимо страждущего...
Но зачем грубить?!
...
Рейтинг: 0 / 0
Структура базы для сложных производственных структур
    #40054897
KreatorXXI
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
rick1177,

я бы объединил т1 и т2. Одинаковые сущности. Сборные объекты связываются с просто покупными позициями через дополнительную таблицу. Таблица продаж - это отдельная таблица. В таблице т1 должна быть цена (и может быть не одна, а также НДС и может быть что-то ещё). В таблице продаж тоже должны быть цена, НДС. При вводе менеджером продажи цена берётся из т1, но менеджер может это всё изменить. И это правильно, потому что цена в т1 может меняться, а таблице продаж не должна. Таблица продаж - это суть две таблицы (шапка, где отправитель, получатель, склады, дата... и позиции). Таблица продаж может быть и таблицей покупок и вообще таблицей документов. Потому что существует много вариантов движений товара (покупка, продажа, перемещение, списание, оприходование излишков, пересортица, уценка).
...
Рейтинг: 0 / 0
Структура базы для сложных производственных структур
    #40055061
L_argo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Сборные объекты связываются с просто покупными позициями через дополнительную таблицу. Накину на вентилятор:
Сборные объекты должны быть привязаны к обезличенным позициям. А привязка обезличенной позиции к реальной меняется во времени.
Пример: приготовление пирожка.
состав: мука, дрожжи, соль, сахар, джем.

Сегодня это мука завода №1, а завтра это будет мука завода № 5.
"Мука" это обезличенная карточка, а "Мука в/с, Завод №5" - карточка конкретного товара.

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

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

- Кухарка №1 берёт килограмм муки завода №1 и лепит пирожок №1
- Кухарка №2 берёт килограмм муки завода №5 и лепит пирожок №2
- Кухарка №1 из той же муки лепит пирожок №3
- Кухарка №2 из той же муки лепит пирожок №4
- Кухарка №3 берёт килограмм муки завода №1, килограмм муки завода №5, сваливает их в одну миску и лепит из них пирожок №5.
...
Рейтинг: 0 / 0
Структура базы для сложных производственных структур
    #40055089
Фотография Relic Hunter
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ЕАV, NoSQL, на выбор.
...
Рейтинг: 0 / 0
Структура базы для сложных производственных структур
    #40055302
s_ustinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
softwarer
L_argo
Сборные объекты должны быть привязаны к обезличенным позициям. А привязка обезличенной позиции к реальной меняется во времени.

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

- Кухарка №1 берёт килограмм муки завода №1 и лепит пирожок №1
- Кухарка №2 берёт килограмм муки завода №5 и лепит пирожок №2
- Кухарка №1 из той же муки лепит пирожок №3
- Кухарка №2 из той же муки лепит пирожок №4
- Кухарка №3 берёт килограмм муки завода №1, килограмм муки завода №5, сваливает их в одну миску и лепит из них пирожок №5.


о да...

В результате получается, что количество табличек приблизится к 30-50. И это только для товаров.

А если добавить условие, что покупатель может заплатить частично карточкой кешбека, а частично наличными - еще больше табличек.
А если еще вспомнить про разные валюты...
...
Рейтинг: 0 / 0
Структура базы для сложных производственных структур
    #40055314
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
s_ustinov
В результате получается, что количество табличек приблизится к 30-50

Вопрос не в количестве. Кейс показывает, что "привязка" как минимум совершенно не "по времени", а если подумать, так и вообще не привязка.
...
Рейтинг: 0 / 0
Структура базы для сложных производственных структур
    #40055323
s_ustinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
softwarer
s_ustinov
В результате получается, что количество табличек приблизится к 30-50

Вопрос не в количестве. Кейс показывает, что "привязка" как минимум совершенно не "по времени", а если подумать, так и вообще не привязка.

Я согласен, что не в количестве.
Я про то, что если мы переходим от простых "учебных" примеров к задачам из реальной жизни - структура базы будет весьма сложной. Далеко не 3-4-5 таблиц. ))

Те же товары - заменители. Когда подшипник с более высоким классом точности может заменить подшипник с более низким классом точности (разве что цена выше). А вот наоборот - нет.
А если начать решать реальные задачи для производства, там все совсем сложно становится. Это я к теме топика.
...
Рейтинг: 0 / 0
Структура базы для сложных производственных структур
    #40055525
zeon11
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
rick1177,

Предположим, варим суп с фрикадельками, продаем готовый суп, продаем полуфабрикаты-фрикадельки, продаем сырую картошку.

1. Одна таблица товаров, древовидная.
В таблице товаров на первом уровне классы простых товаров - картофель, мясо, яйцо, крупы, жиры
Там-же есть класс сборных товаров - Супы, Каши, фрикадельки.
Ни продать, ни купить, ни что-то приготовить из первого уровня нельзя, определяется логикой приложения.
При покупке товара, формируется партия товара, со своей ценой, поставщиком и т.п. и этот товар фиксируется в нашей
древовидной таблице в подчинении соответствующей группы. Например, если мы купили три раза мясо у разных поставщиков, то в группе Мясо появятся три партии товара "мясо", которое уже можно пустить или в продажу, или на производство.

2. Таблица названий рецептур и таблица состава рецептур.
в табл. названий рецептур простые названия, например фрикаделька мясная, каша рисовая, суп с фрикадельками. В табл. состава рецептур товары из первого уровня табл. Товары, в рецептуру могут входить и сборные объекты, такие как фрикадельки.

3. Табл. производства и табл. закладки.
В таблице производства храним информацию о дате производства, исполнителе и т.п. ссылку на вновь произведённый товар, а в таблице закладки храним набор продуктов из товаров партий, таблица закладок формируется на основе таблицы состава рецептур.

Как это все работает?
1. Закупками товара формируем товарные запасы.
2. Технолог определяет рецептуру фрикаделек и рецептуру супа с фрикадельками.
3. Генеральный директор столовой определяет план на 1000 порций супа и на 3000 фрикаделек (2000 фрикаделек пойдут в суп, а 1000 отдельно продадут)
4. В соответствии с планом и рецептурами кладовщик выдаст необходимое количество товаров в цех фрикаделек и в цех супов.
5. цех фрикаделек сделает 3000 фрикаделек, из них 2000 передаст в цех супов, а 1000 передаст в магазин.
6. цех супов примет 2000 фрикаделек и заложит их в 1000 порций супов, передаст 1000 порций супов в магазин.

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

Нету. Потому что внезапно суп это не кучка компонентов, сваленных в один пакет.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Структура базы для сложных производственных структур
    #40055535
Злой Бобр
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
rick1177,

Смотри реализацию товаров и комплектов (наборов). По сути я знаю 3 варианта (может их больше но я не в курсе). В зависимости от ситуации выбирается нужный вариант. Если задача учебная то тут может быть так, что решение которое придумывают теоретики значительно отличается от практиков. Так что лучше обращаться с вопросами к конкретному теоретику. Если задача реальная то сначала смотрите варианты из интернета - 90% вопросов отпадет. Ну а тут уже уточняйте детали того что не поняли.

По вашему первому посту исходя из практики в т.1 будут и товары и наборы. В более распространенных решениях по EAV в т.2 будет состав комплекта. В т.3 будут цены. Дальше таблицы счетов, накладных, клиентов, ... В общем очень скромно 10-12 таблиц, а может и больше.

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

1. Одна таблица товаров, древовидная.

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

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

Как только начинаешь решать более - менее сложные задачи в области финансов, ERP и т.п., это все становится неудобно, и в целом для таких задач удобнее использовать РСУБД. Очень много написано статей на эту тему.
...
Рейтинг: 0 / 0
Структура базы для сложных производственных структур
    #40055670
Злой Бобр
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
s_ustinov
zeon11
rick1177,

1. Одна таблица товаров, древовидная.

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

На самом деле вы немного не правы. Хранить товары, наборы, ... в одной таблице - вполне жизнеспособный вариант. Хотя товарищ действительно написал полный бред о невозможности покупок и продаж. Но это сути не меняет - вариант рабочий. Просто далеко не каждый готов идти по этому пути, как собственно и зависит от конкретной задачи. Большинство выбирает более простой путь EAV.
...
Рейтинг: 0 / 0
Структура базы для сложных производственных структур
    #40055693
s_ustinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Злой Бобр
s_ustinov
пропущено...

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

На самом деле вы немного не правы. Хранить товары, наборы, ... в одной таблице - вполне жизнеспособный вариант. Хотя товарищ действительно написал полный бред о невозможности покупок и продаж. Но это сути не меняет - вариант рабочий. Просто далеко не каждый готов идти по этому пути, как собственно и зависит от конкретной задачи. Большинство выбирает более простой путь EAV.

Хранить наборы товаров как товары (в той же таблице) - да, вполне жизнеспособный вариант и правильный. Более правильный, чем хранить наборы в отдельной таблице.

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

....пока в задачу не вклинится группировка товаров по товарным группам и эти группы не
станут иерархией. Хотя, конечно, обычно её выносят в отдельную таблицу, но вариант когда
всё дерево в одной таблице тоже вполне жизнеспособен (а для некоторых целей и проще).
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Структура базы для сложных производственных структур
    #40055715
zeon11
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
s_ustinov
zeon11
rick1177,

1. Одна таблица товаров, древовидная.

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

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

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


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

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


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