Подтвердить что ты не робот

Рекомендации: сохранение состояния рабочего процесса элемента в базе данных?

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

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

Сначала я подошел к этому, добавив три поля в таблицу "BoxItems" для каждой интерактивно-интерактивной задачи, которая должна быть выполнена:

IsTaskNameComplete

DateTaskNameComplete

UserTaskNameComplete

Это сработало, когда рабочий процесс был прост... но теперь, когда он вырос до сложного процесса ( > 10 возможных человеческих взаимодействий в потоке... примерно половина из которых является необязательной и может быть или не быть выполнена для BoxItem, в результате чего я начал добавлять поля "DoTaskName" также для этих необязательных задач), я обнаружил, что в том, что должно было быть простой таблицей, теперь имеется около 40 полей, полностью посвященных сохранению этой информации о состоянии.

Я спрашиваю, нет ли лучшего способа сделать это... но я в недоумении.

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

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

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

Что бы вы сделали в этой ситуации?

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

EDIT:

Кев, ты говоришь о том, чтобы сделать что-то вроде этого:

BoxItems

(PK) BoxItemID

(Другие нерелевантные вещи)

BoxItemActions

(PK) BoxItemID

(PK) BoxItemTaskID

IsCompleted

DateCompleted

UserCompleted

BoxItemTasks

(PK) Тип задачи

Описание (если требуется)

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

Так вы упомянули Кина, или я на нем?

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

EDIT FINAL: Итак, в суммировании, если кто-то еще смотрит в будущее с тем же вопросом... похоже, что подход сериализации был бы полезен, если ваша система имеет информацию, предварительно загруженную в какой-то интерфейс, где (т.е. напрямую не обращаться к самой базе данных, как работает специальная система, над которой я работаю), но если у вас этого нет, идея дополнительных таблиц кажется, что она должна работать хорошо! Спасибо всем за ваши ответы!

4b9b3361

ОТВЕТЫ

Ответ 1

Если я правильно понимаю, я бы добавил таблицу BoxItemTasks (просто таблицу перечислений, правда?), затем таблицу BoxItemActions с внешними ключами в BoxItems и BoxItemTasks для какой задачи она есть. Если вы хотите сделать это так, чтобы конкретная задача могла выполняться только один раз в определенном элементе окна, просто сделайте пар (Items + Tasks) пары столбцов первичным ключом BoxItemActions.

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

Что касается определения текущего состояния, вы можете написать триггер на BoxItemActions, который обновляет один столбец BoxItems.LastAction. Для одновременных действий у вашего триггера могут быть только особые случаи, чтобы решить, какое действие требует времени.

Ответ 2

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

BoxItemActions, содержащий список действий, которые должен пройти рабочий процесс, созданный каждый раз при создании BoxItem. В этой таблице вы можете отслеживать подробные даты \times\users, когда каждая задача была завершена.

При таком типе приложений знание того, где Box должно идти дальше, может оказаться довольно сложным, поэтому наличие "Карты" остальных шагов для Box окажется весьма полезным. Кроме того, эта таблица может группироваться как сумасшедшая, сотни строк в поле, и ее все равно будет очень легко запросить.

Это также позволяет иметь "разные пути", которые легко могут быть изменены. Таблица основных данных "путей" через рабочий поток является одним из решений, где, когда создается каждый ящик, пользователь должен выбрать, какой "путь" будет следовать за полем. Или вы можете настроить так, чтобы при создании пользователем поля они выбирали задачи для этого конкретного поля. Зависит от нашей деловой проблемы.

Ответ 3

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

Затем в вашей базе данных есть простая структура двух таблиц. В таблице BoxItems хранятся основные данные BoxItem. Тогда таблица BoxItemActions очень похожа на решение, которое вы отметили в качестве ответа.

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

Ответ 4

Для того, что стоит, в BizTalk они "обезвоживают" длительные шаблоны сообщений (рабочие процессы и т.п.) посредством двоичной сериализации их в базе данных.

Ответ 5

Я думаю, что я бы сериализовал объект Workflow в XML и сохранил в базе данных столбец идентификатора. Сложнее сообщить об этом, но похоже, что это может сработать в вашем случае.