architectures de stockage de données enfichables

Question

J'ai un outil de gestion de système enfichable. L'architecture de ce genre de chose est bien comprise (interfaces, publish/subscribe, ....). Que diriez-vous du magasin de données cependant. Que font les gens?

J'ai besoin des plugins pour pouvoir ajouter de nouvelles entités, étendre les entités existantes, établir de nouvelles relations, etc.

Mes pensées (SQL), pas nécessairement bien pensé

• chaque plugin simplement étend le schéma lorsqu'ils sont installés. Auparavant, changer le schéma était un grand non-non; maintenant les bases de données sont très détendues à ce sujet

• Les plugins ont leurs propres tables. Si deux d'entre eux ont une entité (par exemple) personne, alors il y a 2 tables p1_person et p2_person

• plugins ont leur propre base de données

• inventent une sorte de système souple où les tables sont tapés doucement. Peut-être que de nombreux attributs sont regroupés dans un seul attribut. L'ultime est d'avoir une grande table appelée données, avec une clé de nom de table & nom de colonne et une seule valeur de données.

pas SQL

• DB objet. Je n'ai aucune expérience avec ceux-ci. N'importe qui se soucie de transmettre son expérience. db4o par exemple. Puis-je changer le « schéma » des objets que l'application évolue

NO-SQL

• c'est « où son » pour le moment. La plupart d'entre eux semblent viser un peu différemment de mes besoins. Tout le monde veut transmettre l'expérience avec ces

Toutes mes excuses pour la question ouverte

Answer 1

Ma suggestion est d'aller lire sur le cadre de l'entité

beaucoup de situations que vous décrivez peut être résolu (très élégamment) en utilisant l'héritage de la table.

Votre idée d'une grande table de données appelé fait les hamsters dans mon cri informatique;)

La tendance générale est loin de schémas faiblement typés parce qu'ils ne peuvent pas être débogués au moment de la compilation. Ce que vous obtenez de quelque chose comme un framework d'entité est un schéma fortement typé extenislbe que vous pouvez utiliser avec linq.

Base de données d'objets: comme vous je n'ai pas joué avec massivley - mais le moment où je les considérais était un moment où il n'y avait pas de bon ORM pour .net et l'écriture du code ado.net me tue lentement. Comme pour NO-SQL, ce sont des bases de données qui répondent à un besoin de performance.

SQL fonctionne mal dans les situations ici il y a beaucoup de petites écritures se produisent. Je dis mal le tounge dans la joue - il fonctionne très bien mais quand vous faites des économies à des millions d'utilisateurs simultanés tout change.Ma compréhension de no sql est que c'est un format non rationalisé conçu pour beaucoup de petites écritures et lectures rapides. L'échelle des sites qui les utilisent est généralement très grande.

OK - Je suis actuellement assez chanceux en réponse

être sur un projet sur le terrain vert, donc je suis en utilisant EF pour générer mon schéma. Sur les projets non greenfield, j'utilise des scripts SQL pour mettre à jour mes structures de tables. En ce qui concerne l'implémentation de l'héritage des tables dans sql, c'est très facile une fois que vous connaissez le concept, c'est essentiellement une relation un à plusieurs avec une contrainte qui ne sera jamais que de 0-1.

Je ne voudrais pas écrire de code .net qui met à jour la structure de la base de données ... cela ressemble à une catastrophe qui m'attend. Je commence à penser que j'ai mal compris ce que vous cherchez. Je trouve que les bases de données sont une seconde nature car j'ai passé tellement de temps avec elles.

Je n'ai pas trouvé de remplaçant pour être méticuleux au sujet de la gestion de script.