Обобщение заказов на работу

Здравствуйте, stackruians,

Я работаю над дизайном столов для заказов на работу.

Эта проблема:

  • Существуют разные модели рабочих заданий (отныне называемые WOM).
  • WOM имеют общие атрибуты (Num, Date, Description, ... и т. Д.)
  • У WOM есть детали, такие как:
    • Секторы, на которых работа выполнена.
    • Некоторые WOM используют резервуары для хранения вместо секторов (продукты готовятся в резервуарах для хранения).
    • Продукты и их количество (плюс или нет информации о продукте), применяемые в данном секторе.
    • Человеческие ресурсы, которые работали над WO.
    • Материалы, использованные при оформлении заказа
    • ... так далее

Что нужно

  • Разработка таблиц для заказов на работу и детали оф.
  • Они хотят знать, как были потрачены ресурсы.
  • Разработка запросов для получения всех форм информации.

Ограничения

  • Простая презентация для конечных пользователей.
  • Обобщение моделей рабочих заданий.

Что сделано

Разработаны все рабочие задания и их детали в виде иерархии, начиная с номера рабочего задания в качестве родительского узла.

WorkOrderTable (ID, ParentID, Type, Value)

Пример рабочего задания Преобразование иерархических данных в плоскую таблицу

ID  ParentID    Type        Value
38  0           Num         327
39  38          Sector      21
40  38          Sector      22
43  40          Product     NS
44  40          Product     MS
50  40          Temp        RAS
48  44          Quantity    60
47  43          Quantity    25
41  39          Product     ARF
42  39          Product     BRF
49  39          Temp        RAS
51  39          Cible       Acarien A.
46  42          Quantity    30
52  42          Cible       Acarien B.
45  41          Quantity    20

Вопрос

Легко ли поддерживать работу, которую я делаю хорошо / эффективно, или есть другие идеи?

ОБНОВЛЕНИЕ I: Подробнее

  • Продукты не меняются около 50 активных [продукты меняются со временем, нужно отслеживать версию]
  • Секторов около 40 (фиксированная площадь земли)
  • Люди нормальные HR таблицы
  • Насколько большой типичный WOM:
    • около 15 атрибутов (3 из них mportante и общие для всех WOM, остальные чуть меньше)
    • около 5 или более деталей обмена: продукт, сектор, люди и другие, описывающие информацию, такую ​​как количество продукта.
  • Сейчас WOM исправлены, но я беспокоюсь о том, что они изменятся в будущем (или появятся новые)
  • Версионирование сейчас не является обязательным требованием, но добавление его является плюсом.
  • Я планирую использовать разные таблицы для участников (секторы, продукты...)
  • Конфликт метаданных / данных - вот о чем эта дилемма проектирования.
    • Считается, что любая WOM определяется 3 частями:
    • Общая информация о рабочем задании (Num, Date, ...)
    • Секторы [Другие WOM используют хранилище резервуаров], в которых выполняются работы.
    • Ресурсы для завершения работы продуктов, людей, машин...

Состояние дизайна

  • Конкретные таблицы для участников секторов, людей, машин...

  • Таблица метаданных (ID, метаданные, lvl). Пример:

    • Сектор, 1 (непосредственно в WO)
    • Резервуар для хранения, 1
    • Продукт, 2 (может быть частью секторальной работы, а не непосредственно в WO) SD

  • В таблице рабочих заданий (ID, parentID, metadataID, valueID) идентификатор значения берется из таблицы участников

Относительно XML у меня нет никакой информации о том, как хранить их и манипулировать ими.

Источник

2 ответа

Решение

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

  • Сколько пользователей?
  • Сколько продуктов / мест / секторов / людей...?
    • Это изменение данных?
  • Сколько WOM?
  • Насколько велика одна типичная WOM?
  • Это простая иерархия деревьев
    • Если нет: могут ли быть альтернативные маршруты, круги, острова?
  • Исправлены ли эти WOM или они изменились?
    • Если меняется: вам нужно управление версиями?

Похоже, пытаясь изобрести профессиональную ERP-систему. Как уже сказал вам Боствик, вы должны подумать об использовании существующего...

Просто некоторые общие советы:

Источник

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

При этом вы спрашиваете совета по дизайну, но даете только абстрактную информацию. Масштаб системы, ожидаемое количество CRUD и ряд других факторов необходимо учитывать при проектировании. Без подробностей и целей очень сложно ответить на ваш вопрос. Есть компромиссы с разными подходами. Может быть даже целесообразно использовать решение nosql.

При этом я бы посоветовал не создавать собственную ERP- систему, а вместо этого купить ее у поставщика, который является отраслевым, и применить к ней ваши настройки.

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

Если вы просто хотите получить больше опыта, написав это, я бы порекомендовал просмотреть github и ранее упомянутый обмен стека.

Источник
Другие вопросы по тегам