Workflow сайта - Админцентр дизайн советы

Question

фон:

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

Некоторые могут спросить, «Это звучит очень похоже на программное обеспечение другой Workflow Management (WMS), которая уже существует, то почему бы не использовать это?»

В дополнение к этот сайт отслеживает каждую фазу, как и другие инструменты WMS, ей также необходимо напрямую взаимодействовать с другими системами (разными доменами) и программным обеспечением (API/WMI) непосредственно со страниц. Это позволит нашим администраторам поддерживать объекты групповой политики Active Directory, обеспечить правильное инициализацию новых компьютеров правильными настройками, контролировать точность базы данных SQL на удаленных компьютерах и многое другое. И для тех, кто считает, что это важно для вопроса ... В настоящее время я планирую создать веб-сайт с помощью .NET.

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

Вопрос:

В опыте каждого, что ты нашел, чтобы быть лучшим способом для хранения больших объемов данных, что требует новых изменений данных часто?

Начальные мысли:

SQL/База данных для хранения:

Плюсы:

• Легко хранит большие объемы данных.
• Возможность связывать проекты/фазы/задачи с помощью первичных и внешних ключей
• Хранимые процедуры на задней панели помогут с манипулированием базой данных и позволяют изменять запросы без необходимости перекомпилировать сайт. (! Big Plus)

Минусы:

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

XML/YAML/Любой язык разметки

Pros:

• легко манипулировать с "идти-вперед" изменения точки зрения.
• Легко создавать новый «узел» под каждой стадией задачи, которая может обновлять веб-страницы.

Минусы:

• Сохранение данных в файлы имеют высокую летучесть (файлы могут быть удалены, и никаких данных не восстановить).
• Потенциальные проблемы с пользователями, пытающимися получить доступ к файлам в одно и то же время, будут вызывать ошибки (необходимо было бы встроить «блокировки» в код для чтения/обработки данных файлов).

Итоговые комментарии:

Я склоняюсь к памяти SQL/Database, но не вижу изменений в конструкции/рамки будучи быстрым подвигом. Если есть какие-то методы хранения данных, которые я оставляю, которые могут быть потенциально лучше подходят для решения, пожалуйста, дайте мне знать.

Спасибо всем.

Answer 1

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

{ 
"id": 43233, 
"name": "MyProject", 
"created": "02/01/2017", 
"owner": { 
"id": 32132, 
"name": "John Smith" 
} 
"tasks": [ 
{ 
    "id": 43243, 
    "name": "Task1", 
    "priority": "high", 
    "status": "new" 
}, 
{ 
    "id": 43253, 
    "name": "Task2", 
    "priority": "low", 
    "status": "done" 
} 
]} 

База данных документов может быть более подходящим для вас, если ваше приложение не нужно делать много запросов по проектам и работает в основном с одним проектом. Документные базы данных, такие как MongoDB, CouchDB, Azure Document DB и т. Д., Имеют меньшее ограничение на схему данных и, как правило, масштабируются намного лучше, чем база данных SQL.

Итак, вы можете проще изменить схему объекта проекта, добавив новые атрибуты. Получение объекта проекта также будет намного проще - вам не нужно делать много SQL-соединений для «построения» проекта.

О производительности: это зависит от того, как вы собираетесь использовать БД. Для приведенного выше примера вы будете иметь:

1. Чтобы создать проект - один вставку в документе дб против 4 вставок (проекта, владелец, 2 задания) в SQL
2. Чтобы получить проект - один прочитанный против одного довольно сложного выбора с присоединяется. Чем сложнее объект проекта, тем больше будет оператор select.
3. Но если вам нужно получить проекты приложений или задачи, отфильтрованные по некоторым критериям, то SQL будет более удобным и, по-видимому, имеет лучшую производительность.