Я хочу смоделировать сборочную линию в SQL Server. Этот объект будет продвигаться через линейный набор шагов. Каждый шаг будет иметь линейный набор статусов: Ожидание, В процессе и Завершено. Какой подход лучше всего подходит для сбора данных об изменении шага и/или состояния? Вставить одну запись для объекта и обновить поле шага и поле состояния при изменении этих свойств? Или я должен вставлять новую запись каждый раз, когда объект переходит на новый шаг или меняет статус на этом шаге? Я попробовал последнее и обнаружил, что SQL-запросы должны быть сложными.
Моделирование сборочной линии в SQL Server
- Думаю, об этом лучше спросить на stackoverflow.com. 20.07.2009
Ответы:
Это принадлежит Stackoverflow, и я проголосовал за его закрытие. Сказав это, я скажу, что я разработал и внедрил подобные системы (система инвентаризации для производителя запчастей для мотоциклов является самой последней) и гибкость, которую обеспечивает «транзакционная» модель (т. е. выбор «вставить новую запись» ) прекрасен, и его полезность намного перевешивает любую «сложность» в запросах. Использование агрегатных функций "MAX" и "MIN" для полей даты и времени, определяющих время выполнения операции, вместе с квалификаторами "TOP..." в операторах SELECT может значительно упростить сложные запросы.
Если у одного объекта есть только один статус, я предлагаю подход с полем статуса: проще управлять, быстрее запрашивать. Я использовал это решение в некоторых приложениях, и я не видел никаких проблем.
Рабочие процессы в целом лучше всего моделируются с помощью очередей. См. раздел Создание системы агрегации MSDN, и я знаю некоторые настоящие фабрики сборочные линии, которые также используют очереди.
Вы можете сделать и то, и другое: поддерживать «текущее» состояние для каждого объекта и историю продвижения на случай, если вам нужно увидеть, какой путь объект прошел через очередь и сколько времени это заняло в каждом из них. Если для каждого состояния требуется дополнительная информация о состоянии (которая отличается для каждого состояния), вам потребуется создать отдельные таблицы для каждой группы сведений о состоянии или, если вы можете представить ее в виде набора пар ключ-значение, создать простую таблицу свойств. .
Вот грубый пример оформления таблицы:
Object Table:
Id, Name, Description, State
ObjectHistory Table:
Id, ObjectId, Timestamp, State
Properties Table:
Id, ObjectId, Name, Value
--or--
State1Info Table
Id, ObjectId, ...
State2Info Table
Id, ObjectId, ...