Schéma de base de données dynamique

Question

Qu'est ce qu'une architecture recommandée pour fournir un stockage pour une dynamique logique schéma de base de données?

Pour clarifier les choses: Lorsqu'un système est nécessaire pour fournir un stockage pour un modèle dont le schéma peut être étendue ou modifiée par ses utilisateurs une fois en production, quelles sont les bonnes technologies, les modèles de base de données ou de moteurs de stockage qui va permettre cela?

Quelques exemples pour illustrer:

• De la création ou de modification de la base de données des objets via généré dynamiquement DML
• Création de tables avec un grand nombre de éparses physique colonnes et en utilisant uniquement ceux qui sont nécessaires pour le "superposées" logique de schéma
• La création d'une " longue, étroite table qui stocke les dynamiques valeurs de colonnes que de lignes qui doivent ensuite être pivoté pour créer un court, à l'échelle de l'ensemble de lignes contenant toutes les valeurs d'une entité spécifique
• À l'aide d'un BigTable/SimpleDB PropertyBag type de système

Toutes les réponses basées sur l'expérience du monde réel serait grandement apprécié

Answer 1

Ce que vous proposez n'est pas nouveau. Beaucoup de gens ont essayé... la plupart ont trouvé qu'ils chase "infini" de la flexibilité et de la place jusqu'à la fin avec beaucoup, beaucoup moins que cela. C'est le "roach motel" de dessins de base de données -- les données, mais il est presque impossible de le sortir. Essayez et la conceptualisation de l'écriture de code pour TOUTE sorte de contrainte et vous verrez ce que je veux dire.

Le résultat final est généralement un système qui est BEAUCOUP plus difficile à déboguer, à maintenir, et plein de données des problèmes de cohérence. Ce n'est pas toujours le cas, mais le plus souvent, c'est comment elle se termine. Principalement parce que le programmeur(s) de ne pas voir cette épave de train à venir et ne parviennent pas à défensivement code contre elle. Aussi, finit souvent le cas que les "infini" souplesse n'est vraiment pas nécessaire; c'est une très mauvaise "odeur" quand l'équipe de dev obtient une spécification qui dit "mon Dieu, je n'ai aucune idée de quel type de données qu'ils vont les mettre ici, alors let 'em mettre ce que"... et les utilisateurs finaux sont juste très bien avoir pré-définis des types d'attributs qu'ils peuvent utiliser (code générique n ° de téléphone, et laissez-les créer n'importe quel nombre de -- c'est trivial dans un bien normalisé système et maintient la souplesse et l'intégrité!)

Si vous avez une très bonne équipe de développement et sont intimement conscient des problèmes que vous aurez à surmonter avec cette conception, vous pouvez réussir le code bien conçu, pas terriblement buggy système. La plupart du temps.

Pourquoi commencer avec les cotes empilées tellement contre vous, si?

Ne me croyez pas? Google "Une Vraie Table de Recherche" ou "table unique de la conception". Quelques bons résultats: http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:10678084117056

http://thedailywtf.com/Comments/Tom_Kyte_on_The_Ultimate_Extensibility.aspx?pg=3

http://www.dbazine.com/ofinterest/oi-articles/celko22

http://thedailywtf.com/Comments/The_Inner-Platform_Effect.aspx?pg=2

Answer 2

Un champ xml fortement typé dans MSSQL a fonctionné pour nous.

Answer 3

Comme d'autres l'ont dit, il ne faut pas le faire si vous n'avez pas d'autre choix. Un cas où cela est nécessaire, si vous vendez un hors-the-shelf produit qui doit permettre aux utilisateurs d'enregistrer des données personnalisées. Mon entreprise produit tombe dans cette catégorie.

Si vous avez besoin pour permettre à vos clients pour ce faire, voici quelques conseils:
- Créer un solide outil d'administration pour effectuer les modifications de schéma, et ne permettez pas que ces changements soient faits d'une autre façon.
- En font une fonctionnalité d'administration; ne pas permettre aux utilisateurs normaux d'accès.
- Journal tous les détails à propos de chaque changement de schéma. Cela va vous aider à déboguer des problèmes, et il vous donnera également l'ACY données si un client fait quelque chose de stupide.

Si vous pouvez faire ces choses avec succès (surtout le premier), puis l'un des architectures de vous mentionner le travail. Ma préférence est pour changer dynamiquement les objets de base de données, parce que cela vous permet de profiter de votre SGBD de fonctionnalités de requête lorsque vous accéder aux données stockées dans les champs personnalisés. Les trois autres options vous demandent de charger de gros morceaux de données, puis de faire la plupart de votre traitement de données dans le code.

Answer 4

J'ai une exigence similaire et a décidé d'utiliser le schéma de MongoDB.

MongoDB (à partir de "humongous") est une source ouverte, évolutive, de haute performance, de schéma-libre, orientée document de la base de données écrites dans le langage de programmation C++. (Wikipédia)

Faits saillants:

• riche en fonctionnalités de requête (peut-être le plus proche de SQL DBs)
• la production de prêts (foursquare, sourceforge l'utiliser)

Lowdarks (de choses que vous devez comprendre, de sorte que vous pouvez utiliser mongo correctement):

• pas de transactions (en fait, elle a des transactions, mais seulement sur les opérations atomiques)
• ce genre de choses ici: http://ethangunderson.com/blog/two-reasons-to-not-use-mongodb/
• durabilité .. surtout de l'ACIDE choses liées

Answer 5

Je l'ai fait dans un projet réel:

La base de données est composée d'une table avec un champ qui est un tableau de 50. Il avait un " mot " index fixés sur elle. Toutes les données ont été sans type de sorte que le mot "index" a fonctionné comme prévu. Les champs numériques ont été représentés comme des personnages et le tri réelle avait été fait à côté client. (Puisqu'il est toujours possible d'avoir plusieurs champs du tableau pour chaque type de données si nécessaire).

La logique de schéma de données pour les tables logiques a eu lieu au sein de la même base de données avec les différentes lignes de table "type" (le premier élément du tableau). Il a également appuyé le contrôle de version simple de copie sur écriture de style en utilisant le même champ 'type'.

Avantages:

1. Vous pouvez modifier et ajouter/supprimer vos colonnes dynamiquement, pas besoin de dump/rechargement de la base de données. Toutes les nouvelles données de la colonne peut être définie à la valeur initiale (presque) à zéro heure.
2. La Fragmentation est minime, puisque tous les registres et tables sont de même taille, parfois, il offre de meilleures performances.
3. Toutes schéma de la table est virtuel. Tout schéma logique stucture est possible (même récursive, ou orienté objet).
4. Il est bon pour "écrire une fois, principalement en lecture, pas-supprimer/marque-comme-supprimé" des données (la plupart des applications Web sont réellement comme ça).

Inconvénients:

1. L'indexation seulement par les mots, pas d'abréviation,
2. Des requêtes complexes sont possibles, mais avec une légère dégradation des performances.
3. Dépend de votre choix de système de base de données prend en charge les tableaux et les index de mots (c'était inplemented in PROGRESS SGBDR).
4. Le modèle relationnel est seulement dans l'esprit du programmeur (c'est à dire uniquement au moment de l'exécution).

Et maintenant, je suis en train de penser à la prochaine étape pourrait être de mettre en place une telle base de données sur le niveau du système de fichiers. Qui pourrait être relativement facile.