Site Web de workflow – Conseils de design back-end

Context:

Je commence à concevoir / concevoir un nouveau site web qui permettra de suivre le stream de travail d'une grande quantité de projets. Chaque projet se verra atsortingbuer des phases ( planification, mise en œuvre, post-implantation, fermeture, etc … ). Chacune des phases contient différentes tâches, etc.

Certains peuvent requestr, " Cela ressemble beaucoup à d'autres logiciels de gestion de workflow (WMS) qui existent déjà, pourquoi ne pas l'utiliser? "

En plus de ce site qui suit chaque phase comme les autres outils WMS, il devra également interagir directement avec d'autres systèmes (différents domaines) et logiciels (API / WMI) directement à partir des pages. Il permettra à nos administrateurs de gérer les GPO Active Directory, de s'assurer que les nouveaux ordinateurs sont correctement initialisés avec les parameters corrects, de surveiller la fidélité de la database SQL sur les ordinateurs distants et bien plus encore. Et pour ceux qui croient que c'est important pour la question … Je prévois actuellement de build le site en utilisant .NET.

Comme beaucoup d'entre vous le savent, les projets et les normes évoluent rapidement dans le monde des affaires. En tant que tel, je cherche à rendre ce site aussi dynamic et rapide que possible en ce qui concerne chaque phase et chaque tâche. Par exemple, les associés peuvent avoir besoin d'effectuer une tâche supplémentaire sur chaque projet qui n'est pas défini auparavant. Nous devrons ensuite être en mesure de modifier rapidement toutes les inputs de projet actuellement ouvertes et tous les nouveaux projets pour append le nouvel élément à la list de contrôle.

Question:

Dans l'expérience de tout le monde, qu'avez-vous trouvé comme le meilleur moyen de stocker de grandes quantités de données qui nécessitent de nouvelles modifications de données fréquemment?

Pensées initiales:

Stockage SQL / Base de données:

Avantages:

Stocke facilement de grandes quantités de données.
Possibilité de lier les projets / phases / tâches via les keys primaires et étrangères
Les procédures stockées sur le back-end aideraient à manipuler la database et à permettre le changement de requêtes sans avoir besoin de recomstackr le site. ( Big Plus! )

Les inconvénients:

Les nouveaux éléments de list de contrôle nécessiteraient la création de nouvelles colonnes dans chaque table.
La complexité de chaque tâche peut entraîner la jonction d'une grande quantité de tables.
Une fois que de nouvelles colonnes ont été créées, chaque procédure stockée devrait être modifiée pour s'assurer que la nouvelle colonne est incluse dans sa manipulation.

XML / YAML / Any Markup Language

Avantages:

Facilement manipulé à partir d'un sharepoint vue des changements «aller de l'avant».
Facilement peut créer un nouveau "noeud" sous chaque phase de tâche qui peut mettre à jour les pages Web.

Les inconvénients:

L'logging des données dans les files présente une forte volatilité (les files peuvent être supprimés et aucune donnée ne peut être récupérée).
Les problèmes potentiels avec les users tentant d'accéder aux files en même time produiraient des erreurs (il faudrait build des «verrous» dans le code pour lire / manipuler datatables d'un file).

Commentaires finaux:

Je penche pour le stockage SQL / Base de données, mais je ne vois pas de changements rapides dans le design / framework. S'il y a des methods de stockage de données que j'abandonne qui pourraient être un meilleur ajustement à la solution, s'il vous plaît faites le moi savoir.

Merci tout le monde.

Plus de détails sont nécessaires pour vous reorder un stockage spécifique. Mais à partir de votre description, un projet ressemble à un document avec de nombreux attributes et éléments enfants comme celui-ci:

{ "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" } ]}

Une database de documents peut vous convenir si votre application n'a pas besoin de faire beaucoup de requests à travers les projets et travaille principalement avec un projet. Les bases de données de documents telles que MongoDB, CouchDB, Azure Document DB, etc. ont less de ressortingctions sur le schéma de données et sont en règle générale beaucoup mieux mises à l'échelle que la database SQL.

Ainsi, vous pouvez modifier plus facilement le schéma d'object du projet en ajoutant de nouveaux attributes. La récupération de l'object projet sera également beaucoup plus facile – vous n'avez pas besoin de faire beaucoup de jointures SQL pour "build" un projet.

A propos de la performance: cela dépend de la façon dont vous allez utiliser DB. Pour l'exemple ci-dessus, vous aurez:

Pour créer un projet – un insert dans le document db vs 4 inserts (projet, propriétaire, 2 tâches) en SQL
Pour get le projet – une lecture vs une sélection assez complexe avec des jointures. L'object de projet plus complexe que vous avez l'instruction plus select sera.
Mais si vous avez besoin d'get des projets d'application ou des tâches filtrées selon certains critères, SQL sera plus pratique et aura de meilleures performances.