Дизайн базы данных для обновляемых последовательных записей

Question

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

Я пытаюсь моделировать процессы и включать родительские процессы и последовательный порядок процессов.

Например:

Process Table 
--------------------- 
ProcessID - uniqueidentifier 
ProcessName - varchar 
ProcessDescription - varchar 
... 

ProcessOrder Table 
--------------------- 
ProcessID - uniqueidentifier FK - Process 
ParentProcessID - uniqueidentifier FK - Process 
ProcessOrder - int 
... 

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

Например, процедура моделирования имеет следующие шаги: создать новую пустую модель, модель имени, ввести параметры модели. Process Таблица будет выглядеть следующим образом:

ProcessID | ProcessName | ProcessDescription 
------------------------------------------------- 
UUID1  | Modeling | Create Model of Data 
UUID2  | New Model | create new empty model 
UUID3  | Name Model | name model 
UUID4  | Parameters | enter model parameters 

ProcessOrder Таблица будет выглядеть следующим образом:

ProcessID | ParentProcessID | ProcessOrder 
-------------------------------------------------- 
UUID2  | UUID1   | 1 
UUID3  | UUID1   | 2 
UUID4  | UUID1   | 3 

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

Есть ли лучший способ хранить данные такого рода и поддерживать нормализацию?

Answer 1

Я считаю, что решение похоже на тот, который я был предложен на Advise on database design for a project lifecycle

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

а) Заказчик проект - ClientId - ссылка на клиент - Статус (FK в ProcessId) - название проекта, описание, дата начала

б) изменения статуса - который отслеживает изменения от одного состояния к другому - ProjectID - старый статус (FK для ProcessId) - новый статус (FK для ProcessId) - дата изменила - ноты (и другие столбцы, как утверждение и т.д.)

Answer 2

Проблема аналогична тому, почему LinkedLists имеют лучшую производительность вставки (учитывая, что у вас уже есть ссылка на узел, куда вы хотите вставить), и вставка в ArrayList.

В ArrayList при вставке вам необходимо переместить все записи, чтобы освободить место для новой вставки. Это может занять время O (N), предполагающее N записей (предположим, что вставка начинается в начале списка).

В LinkedList вам нужно только обновить узлы в точке, которую вы хотите сделать. В предположении выше это займет время O (1), так как вам нужно обновить узел Prev и Next.

Чтобы настроить структуру LinkedList в базе данных вместо столбца ProcessOrder, у вас должно быть два столбца: PrevProcessID и NextProcessID.

Проблема возникает при выборе этого варианта. Наивный подход состоял бы в том, чтобы рекурсивно объединиться на столе. Это приведет к объединению N.

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

В коде есть объект процесса со следующими полями: ParentProcessID ProcessID PrevProcessID NextProcessID

При чтении в записях из избранных, создавать эти объекты и хранить их в HashTable с ProcessId как ключ. Это займет время O (N), чтобы выполнить цикл с помощью оператора select.

Теперь, когда записи находятся в HashTable, вы можете легко перейти от одного узла к следующему, просмотрев NextProcessID (или PrevProcessID) в таблице. Использование HashTable избавляет вас от выполнения N соединений и вместо этого требует O (N) времени для настройки.

Сравнивая два подхода

1) В настоящее время решения у вас есть сейчас. Это решение типа ArrayList (подумайте о ProcessOrder как об индексе). Вставки занимают время O (N), в то время как вы сохраняете время на чтение, потому что вам не нужно настраивать HashTable. Однако, если вы уже перебираете возвращаемые записи для установки объектов сущностей, тогда это будет такое же количество времени установки в решении LinkedList.

2) Мое предлагаемое решение. Это решение типа LinkedList. Вставки принимают время O (1), предполагая, что вы знаете, куда вы хотите вставить. Время установки занимает время O (N).