Как связывать предприятия, филиалы, склады, стеллажи, ящики в иерархической структуре?

Рейтинг: 2Ответов: 1Опубликовано: 26.01.2015

Пишу программу складского учета (не лаб). Поставщики, покупатели и "мой фирмы" в таблице "контрагенты" вместе ("мой фирмы" от поставщиков и покупателей различаю по реквизиту "MyFirm").

Часть диаграммы:

alt text

Хочу создать иерархическую структуру типа:

*   Фирма №1
 *     филиал(магазин)№1
     *         склад №1(основной, для товара)
            *  стеллаж №1 
            *  стеллаж №2
             *  ящик №1(часто используется,напр, в аптеках)
             *  ящик №2 
      * склад №2(для материалов) 
      * склад №3(для списанного товара,пока налоговая не разрешить уничтожить)       
 * филиал(магазин)№2
       *      склад №1
* Фирма №2  
 и т.д.

То есть сначала, когда клиент создаст свою фирму, в таблице MyFirms его фирма не вставляется, она будет в контрагентах и MyFirms таблица связывается с таблицей "контрагенты" через ID.

Мой вопросы:

1) Как создать такую древовидную структуру?

Если в таблице склады добавлю поле ParentID, тогда смогу создать записи стеллажей и ящиков и построить иерархию склада типа: 

*  Склад №1
     *   стеллаж №1
       *    ящик №1   
       *  ящик №2   
     *   стеллаж №2
       *  ящик №3
       *  ящик №4 
*  Склад №2 
     *   стеллаж №3
       *  ящик №5
       *  ящик №6 
и т.д.

Если в таблице Контрагенты добавлю поле ParentID, тогда смогу вставить в таблице записи филиалов и подразделении и построить иерархию типа:

 *  Фирма №1
      *  филиал(магазин)№1
        *  подразделение №1   
        *  подразделение №2   
      *  филиал(магазин)№2
        *  подразделение №3
        *  подразделение №4 
 *  Фирма №2 
      *  филиал(магазин)№3
        *  подразделение №5   
        *  подразделение №6
и т.д.

Но это не та иерархия - получу 2 отдельные иерархии без связи между ними. А мне нужен другая иерархия (см. вверх).

2) Если иерархию построю по-другому (т.н. "структура с потабличным хранением уровней", т.е. цепь связанных таблиц: фирмы-филиалы-подразделения-склады-стеллажи-ящики и т.д.), тогда какую иерархию построить - у одних фирм не будет стеллажи и таблица будет пустая, у других ящики, а третьи захотят добавить что-то другое, и для них придётся создать дополнит. таблицу. Как запихнуть для них в этой предопределенно созданной цепи справочников новый справочник, то есть новую таблицу?

Как? Что-то сильно запутался, прошу помочь/поправить/дать предложения. Заранее спасибо.

база-данных
Источник: Stack Overflow на русском

Ответы

▲ 1Принят

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

UPD
Первое.
Указанная вами статья - про однородную иерархию, где каждый уровень является представлением одного и того же только более подробно. Как пример: каталог, где каждому к узлу могут быть привязаны товары. т.е. что 1-й уровень, что n-й равноправны и пользователь при вводе данных будет иметь возможность выбрать любой элемент в иерархии.
У вас другая ситуация, каждый уровень является самостоятельной сущностью. Кроме того, статья 2007 года, есть и более правильные реализации древовидных структур (альтернативные стандартной id-parent-level), в частности nested sets

Второе.
Либо вы пишите под конкретную фирму, где используется приведенная вами иерархия, и реализуете ее по любому из приведенных вами методов. Либо отказываетесь от иерархии вовсе (о чем, собственно говоря, мой ответ изначально был и есть). Вот вам примеры:

  1. Организация - продуктовая палатка. Филиалов нет, склад представляет собой отгороженный уголок в той же палатке, как следствие, ни стеллажей, ни ящиков, ни паллет нету.
  2. Холдинг представляет собой совокупность из 10 юрлиц, при этом товар располагается на 4-х складах, один из которых оптовый. На каждом складе товар может принадлежать как одной организации, так всем 10 (возникают внутрихолдинговые перемещения, связанные с лицензиями на продажу и т.п.). Оптовый склад имеет 3 этажа, на каждом из которых располагаются контейнеры, которые приходят-уходят, часть разбирается - в розницу, в том числе на том же складе - по боксам, паллетам...
  3. Ну, можно долго продолжать, дурное дело - не хитрое.

Вы подходите к задаче, имея какое-то свое представление о всей системе. При этом пытаетесь сразу учесть и товарный учет и логистику и зарплату (судя по схеме в вопросе).
Постарайтесь решать задачу как можно более общо (если есть желание угодить многим пользователям), и при этом решение должно быть как можно более простым.

Например.

  • Организация - реквизит всех документов, т.е. чьи товары с точки зрения бухгалтерии вы учитываете.
  • Склад - также реквизит всех документов товародвижения. Связи с организациями у склада нет.

Для реализации учета товаров большего не нужно. Иерархии тоже.

Логистика - это другая задача, где важны точные "адреса", те самые стеллажи и ящики. Эти параметры относятся даже не к товару, а к конкретным упаковкам. И никто кроме кладовщика про них не знает и не должен знать. Кладовщик мог принять товар, а потом рассортировывать по своим стеллажам или делать это в процессе освобождения каких-либо ящиков. Такие пертурбации с хранящимся товаром имеют смысл только внутри склада, и если и есть документальные подтверждения таких перемещений (для больших складов актуально), то учету и бухгалтерии и прочим дела до них нет. Отсюда следует, что не может существовать такого отчета, где были бы одновременно и Фирма и Ящик, тем более в одной иерархии.