Lorsque vous ne devez pas utiliser une base de données relationnelle? [fermé]

Question

En dehors du scénario google / BigTable, lorsque vous ne devez pas utiliser une base de données relationnelle? Pourquoi ne pas, et ce que vous devez utiliser? (Avez-vous appris la dure »?)

Answer 1

Dans mon expérience, vous ne devez pas utiliser une base de données relationnelle lorsque l'un de ces critères sont remplies:

• vos données est structuré comme une hiérarchie ou un graphique (réseau) de profondeur arbitraire,
• le modèle d'accès typique de lecture sur l'écriture met l'accent, ou
• il n'y a pas d'obligation pour les requêtes ad hoc.

hiérarchies profondes et graphiques ne se traduisent pas bien aux tables relationnelles. Même avec l'aide d'extensions propriétaires comme Oracle CONNECT BY, chassant les arbres est une douleur puissante en utilisant SQL.

Bases de données relationnelles ajouter beaucoup de frais généraux pour un accès simple lecture. l'intégrité et transactionnelles de référence sont puissants, mais surpuissant pour certaines applications. Donc, pour les applications en lecture pour la plupart, une métaphore de fichier est assez bon.

Enfin, vous simplement ne pas besoin d'une base de données relationnelle avec son langage de requête entière s'il n'y a pas de requêtes inattendues prévues. S'il n'y a pas de costumes poser des questions comme « combien de 5% widgets bleu -discounted ne nous vendons à la côte Est regroupés par vendeur? », Et il ne le sera jamais, vous, monsieur, pouvez vivre sans DB.

Answer 2

Le paradigme de la base de données relationnelle fait certaines hypothèses sur l'utilisation des données.

• Une relation est constituée d'un ensemble de lignes non ordonnée.
• Toutes les lignes dans une relation ont le même ensemble de colonnes.
• Chaque colonne a un nom fixe et le type de données et la signification sémantique sur toutes les lignes.
• Les lignes dans une relation sont identifiées par des valeurs uniques dans la colonne de clé primaire (s).
• etc.

Ces hypothèses prennent en charge la simplicité et de la structure, au prix d'une certaine flexibilité. Toutes les tâches de gestion des données intègrent dans ce genre de structure. Les entités avec des attributs complexes ou des attributs variables ne sont pas, par exemple. Si vous avez besoin de flexibilité dans les zones où une solution de base de données relationnelle ne le supporte pas, vous devez utiliser un autre type de solution.

Il existe d'autres solutions pour la gestion des données avec des exigences différentes. La technologie Web sémantique, par exemple, permet à chaque entité de définir ses propres attributs et d'être auto-description, en traitant les métadonnées comme attributs comme données. Ceci est plus souple que la structure imposée par une base de données relationnelle, mais que la flexibilité est livré avec un coût propre.

Dans l'ensemble, vous devez utiliser le bon outil pour chaque tâche.

Voir aussi mon autre réponse à « La prochaine génération bases de données d'. «

Answer 3

Il existe trois principaux modèles de données (C.J.Date, E.F.Codd) et je suis l'ajout d'un fichier plat à ceci:

• fichier plat (s) (la structure varie - d'un texte plat « stupide » à des fichiers conformes à grammaires qui accouplées avec des outils intelligents faire des choses très intelligentes, des compilateurs pensent et ce qu'ils peuvent faire, l'application étroite dans la modélisation de nouvelles choses)
• hiérarchique (arbres, ensembles imbriqués - exemples: XML et autres langages de balisage, registre, organisation graphiques, etc., tout peut être modélisés, mais les règles d'intégrité ne sont pas faciles à exprimer et la récupération est difficile d'optimiser automatiquement, une récupération est rapide et certains est très lent)
• (réseaux, graphiques - exemples: bases de données de navigation, liens hypertextes, web sémantique, encore une fois presque tout peut être modélisé, mais l'optimisation automatique de récupération est un problème)
• relationnelle (première logique sous-jacente de l'ordre - exemple: bases de données relationnelles, optimisation automatique de récupération)

Les deux hiérarchique et le réseau peut être représenté en relationnel et relationnel peut être exprimé dans les deux autres.

La raison pour laquelle relationnelle est considéré comme « meilleur » est la nature déclarative et normalisation non seulement la langue de la récupération des données, mais aussi sur la langue de définition de données, y compris la forte intégrité des données déclaratives, sauvegardées avec stable, évolutive, système de gestion multi-utilisateurs.

Les avantages ont un coût, que la plupart des projets trouvent être un bon rapport pour les systèmes (multi applications) qui stockent des données à long terme dans un de qui sera utilisable dans un avenir prévisible.

Si vous n'êtes pas la construction d'un système, mais une seule application, peut-être pour un seul utilisateur, et vous êtes à peu près certain que vous ne souhaitez que plusieurs applications à l'aide de vos données, ni plusieurs utilisateurs, dans un proche avenir, alors vous aurez probablement trouver plus rapidement des approches.

Aussi, si vous ne savez pas quel genre de données que vous souhaitez stocker et comment le modéliser les points forts du modèle relationnel sont alors gaspillée sur elle.

Ou tout simplement si vous ne se soucient pas de l'intégrité de vos données beaucoup (ce qui peut être très bien).

Toutes les structures de données sont optimisées pour un certain type d'utilisation, que si relationnelles essaie correctement modélisés pour représenter la façon dont la « réalité » dans sémantiquement impartiale. Les gens qui ont eu une mauvaise expérience avec les bases de données relationnelles ne réalisent généralement pas que leur expérience aurait été bien pire avec d'autres types de modèles de données. implémentations horribles sont possibles, et en particulier avec les bases de données relationnelles, où il est relativement facile de construire des modèles complexes, vous pourriez finir avec un certain monstre sur vos mains. Cependant, je me sens toujours mieux quand j'essaie d'imaginer le même monstre en XML.

Un exemple de la façon dont bon modèle relationnel est, OMI, est le rapport de la complexité par rapport brièveté des questions que vous trouverez qui impliquent SQL.

Answer 4

Je vous suggère de visiter le blog de haute Évolutivité , qui traite de ce sujet presque sur une base quotidienne et a de nombreux articles sur projets qui ont préféré distribués hash, etc. sur SGBDR.

La (réponse, mais très incomplète) rapide est que toutes les données se traduit bien aux tables de façon efficace. Par exemple, si vos données est essentiellement un grand dictionnaire, il y a probablement des alternatives beaucoup plus rapide que SGBDR ancienne plaine. Cela dit, il surtout une question de performance, et si les performances ne sont pas une préoccupation majeure dans un projet, et la stabilité, la cohérence et la fiabilité, par exemple, sont, alors je ne vois pas beaucoup d'intérêt à plonger dans ces technologies lorsque SGBDR est un système beaucoup plus mature et bien développé, avec le soutien dans toutes les langues et les plates-formes et un vaste ensemble de solutions à choisir.

Answer 5

système il y a je travaillais sur un risque de crédit Quinze ans (essentiellement un grand système de navigation dans l'arborescence). Nous utilisions Sybase sur HPUX & solaris et performnce était de nous tuer. Nous avons embauché des consultants directs de Sybase qui a dit qu'il ne pouvait pas être fait. Ensuite, nous sommes passés à une base de données orientée objet (magasin d'objets dans ce cas) et a obtenu une une augmentation de la performance 100x (et le code était à peu près 100x plus facile d'écrire trop)

Mais ces situations sont assez rares -. Une base de données relationnelle est un bon premier choix

Answer 6

Lorsque vous schéma varie beaucoup, vous aurez du mal avec les bases de données relationnelles. C'est là les bases de données XML ou des bases de données de paires clé-valeur fonctionnent le mieux. ou vous pouvez utiliser IBM DB2 et avoir des données relationnelles et des données XML gérées par un seul moteur de base de données.

Answer 7

7-8 ans, je travaillais sur un site Web qui a grandi en popularité au-delà de nos attentes initiales et nous obtenu en performance sage problème. Comme nous étions tous les projets basés relativement peu d'expérience dans le web, il a posé une forte pression sur nous de ce qu'il faut faire au-delà de la séparation de la base de données habituelle sur serveur distinct, l'équilibrage de charge, etc.

Un jour, je l'ai pensé à quelque chose d'assez simple. Depuis le site a été basé sur les utilisateurs, leurs profils ont été stockés dans une table de base de données de la personne habituelle façon le ferait - ID utilisateur, beaucoup de variables d'information et des trucs comme ça - qui apparaissent comme le profil d'utilisateur que les autres utilisateurs peuvent rechercher . J'ai envoyé toute ces données dans un simple fichier html, déjà préparé comme une page de profil des utilisateurs et a obtenu un coup de pouce important - essentiellement un cache. J'ai même fait un système lorsque l'utilisateur modifié leurs informations de profil, il analyser le fichier HTML d'origine, mettre en place pour modifier, puis débusquer HTML dans le système de fichiers - GOT encore plus poussée.

J'ai fait quelque chose simillar avec les utilisateurs des messages envoyés à l'autre. Fondamentalement, partout où je pouvais faire un système de dérivation d'une base de données tout à fait, en évitant un INSERT ou UPDATE, je suis un sérieux coup de pouce. Cela peut sembler un sens commun, mais ce fut un moment instructif. Il n'est pas éviter la configuration relationnelle en soi, mais il est un évitement de la base de données tout à fait - KISS.