éditer Je viens de commencer à scrimer le célèbre papier de 1970 de Codd qui a tout commencé, que Oracle était basé sur ( Un modèle relationnel de données pour les grandes banques de données partagées [PDF] ) et a été étonné de constater qu'il semble que cela réponde à cette question. . Il parle de bases de données dans le marché à cette époque ("hiérarchique" et "réseau" - comme NOSQL?), La nécessité d'indépendance de la représentation interne et une explication claire de la manière d'appliquer des relations mathématiques " "À une base de données.
Historiquement, quelle caractéristique de bases de données relationnelles a donné quel avantage qui a amené les entreprises à l'adopter, ce qui la rendant massivement réussie?
Aujourd'hui, il existe de nombreuses raisons d'utiliser une RDB: Son standard est standard, les produits sont matures, débogué, en vedette, il y a un choix de fournisseurs, il y a un soutien, il y a une main-d'œuvre qualifiée et ainsi de suite. Mais pourquoi est-il devenu si populaire?
J'ai entendu " Bases de données hiérarchiques " étaient populaires avant les bases de données relationnelles - elles semblent être une boutique de valeur de clé, où la valeur peut être un autre ensemble de valeurs de clé. Si tel est le cas, cela est similaire aux bases de données orientées objet publiées il y a une décennie ou deux; ainsi que des bases de données XML / Document et NOSQL.
Peut-être Peut-être parce que des bases de données relationnelles vous ont permis de définir un schéma de données qui était purement sur les données - indépendamment d'une langue de programmation particulière, version d'une application (évolution) ou d'un but de la demande (ce fait "inadéquation d'impédance" une inévitable) mais toute base de données avec un schéma de données a cette fonctionnalité.
Peut-être parce que le modèle relationnel Peut-être parce que le modèle mathématique vous permet de réorganiser la base de données dans différentes formes normales pour donner des caractéristiques de performance différentes, garantie mathématiquement de ne pas modifier la signification des données? Cela semble plausible et mes manuels unies en font beaucoup, mais cela ne me convaincait pas comme une prestation commerciale pratique (peut-être que je manque quelque chose)?
Résumer: Historiquement, qu'est-ce que le modèle relationnel gagne de manière si décisive sur le modèle hiérarchique? Je suis également intéressé à si la RDB a toujours une qualité spéciale qui en fait activement un meilleur choix pratique pour les entreprises (autres que les avantages d'être une norme mentionnée ci-dessus).
Merci beaucoup si vous pouvez perdre une lumière - j'ai longtemps été curieux de cela.
5 Réponses :
Pour la même raison pour laquelle les langues de script sont populaires.
Vous pouvez faire une requête avec votre éditeur de texte préféré et simplement le délivrer, sans vous soucier du schéma physique réel.
Ce n'est pas le modèle le plus rapide, pas le modèle le plus fiable - c'est juste le modèle le plus productif. Vous pouvez écrire dix fois plus de questions dans une heure.
Vous voudrez peut-être lire cet article dans mon blog compare les modèles de base de données les plus populaires:
Maintenant, un wiki communautaire - s'il vous plaît n'hésitez pas à modifier / ajoutez! Merci pour votre article, cela semble être juste sur l'argent. J'ai du mal à connecter votre réponse ici et cela, mais je n'ai pas encore lu l'article en détail encore.
De ma connaissance, c'est la théorie de la normalisation (la troisième forme normale du Codd bien connue) de définir le modèle de données relationnel facile et efficace pour le stockage et la récupération. Ceci suivi de la langue de requête standard (SQL) qui lui permet d'utiliser tout le système de DB relationnelle. La normalisation manquait définitivement de retour, qui rend également cet attrait à beaucoup.
Merci - je lisais dans "Traverser le gouffre" que Oracle a dirigé la standardisation sur SQL, en portant leur base de données à tout ce qui est en vue (même si SQL a été développé par IBM). Cette standardisation a contribué énormément aux bases de données relationnelles, mais je crois qu'ils étaient déjà populaires (et ont "gagné" contre les bases de données hiérarchiques) avant à ce moment-là. Qu'est-ce qui a fait la troisième forme normale spéciale par rapport aux autres?
Le concept de représentation logique des données résumées de sa représentation physique était peut-être l'aspect le plus changeant au jeu de l'idée du CODD. Il était apparemment la première personne qui a pleinement compris les avantages de la séparation des préoccupations logiques et physiques et donc le premier à concevoir un modèle de données digne de son nom. En décrivant un modèle basé sur les relations, sans liens de navigation ni structures de pointeur, il a également créé quelque chose de particulièrement puissant, flexible et durable.
Pour être précis, il faut dire que c'était le modèle SQL plutôt que le relationnel qui a finalement été avéré plus performant commercialement. SQL est un long chemin à partir d'un modèle de données ou d'une langue véritablement relationnels, même si cela n'aurait pas été entré sans avoir à être sans idées de Codd pour l'inspirer. Le créateur du modèle relationnel a naturellement déçu que SQL plutôt que relationnel est devenu la norme de base de données. Quatre décennies plus tard, je pense que nous avons beaucoup de cause à regretter que le modèle relationnel de Codd ne soit pas mieux supporté par le logiciel DBMS.
Merci - "Un modèle basé sur les relations [plutôt que] des pointeurs" - cela semble être la réponse, même si j'ai besoin de plus de contexte pour le comprendre. Je me souviens que la distinction logique / physique est soulignée. "SQL plutôt que relationnel est devenu la norme de base de données" - mais n'est-elle pas une mise en œuvre de SQL (partielle) du modèle relationnel? [BTW: Je sens que vous avez laissé un mot lorsque vous comparez SQL et relationnel, car ils semblent être différents types de choses - mais je ne comprends probablement pas le fond assez bien)
Une touche Une fois les produits autonomes - vous n'avez plus eu à définir et à conserver manuellement vos fichiers clés (index) et la possibilité de modifier le modèle de données avec moins d'effort. Combinez qu'avec les structures basées sur l'ensemble, un produit convaincant de fonctionner avec. Combinez la langue SQL en plus de cela pour renvoyer des données et il s'agissait d'une situation gagnant-gagnant sur les structures de données ISAM traditionnelles, principalement associées aux langages COBOL.
Merci - vos 1er et 3ème points semblent avoir une convivialité (autonome et SQL). La même chose n'a pas été mise en œuvre pour le modèle hiérarchique - ou y avait-il quelque chose de différent sur le modèle relationnel qui leur a permis? C'est-à-dire quelle est la fonctionnalité intrinsèque qui a conduit au bénéfice? Votre 2e point (ensemble basé) semble intrinsèque, bien que SQL ne met pas pleinement en œuvre le modèle relationnel, la chose qui est devenue si populaire (SQL) n'est pas réellement "relationnelle", juste des aspects de celui-ci. Je me demande ce qu'ils sont? [Ou peut-être que c'est juste la chance que les fournisseurs ont apporté la facilité d'utilisation de ce modèle]
Premiers et 3ème points: La séparation des données et du code a été distancié - toujours beaucoup de données de données au code avec SQL, mais beaucoup plus faciles à séparer - l'autre a été très étroitement liée et tout en étant possible, très peu a été faite dans ces lignes. Le deuxième point tourne autour de données-récupérer un ensemble plutôt que de devoir faire des trucs comme une jointure manuellement dans le code avec la masse de données, donc moins efficace.
Je crois que aucune des réponses vraiment clouée, comme vous êtes intéressé aspect historique de celui-ci.
Si je singulariser une raison pour laquelle je dirais Quassnoi était proche, mais SQL n'était pas seulement une langue - il a une caractéristique qui n'a pas été commun dans 70:
Je ne pense pas qu'il est possible de trop insister là.
bien sûr, le modèle relationnel est également grand facteur (et est lié à ce qui précède)
Note: certaines des intentions ci-dessus SQL et « R'DBMSes ne livre pas entièrement (et / ou d'autres modèles ont surmonté leurs problèmes d'une certaine façon), mais ceux-ci étaient les intentions initiales et examiner comment SQL stable était dans le passé ~ 40 ans (voici un lien vers le document d'IBM 1974 ) ou il n'a pas fait un si mauvais, mauvais travail soit.
Il y a aussi cette citation de < / p>
« idée de base de Ted était que
les relations entre les éléments de données
devrait être fondée sur les valeurs de l'élément,
et non pas spécifié séparément
reliant ou l'imbrication. cette notion
grandement simplifié la spécification
des requêtes et a permis sans précédent
la flexibilité d'exploiter les données existantes
ensembles de nouvelles façons « , a déclaré Don
Chamberlin, co-inventeur de SQL, la
langue standard pour
l'interrogation bases de données relationnelles, et
la recherche membre du personnel à Almaden. "Il
croyaient que les utilisateurs d'ordinateurs devraient être
capable de travailler à un plus
niveau de langue naturelle et ne pas être
préoccupé par les détails de l'endroit où
ou comment les données ont été stockées. »
Lors d'une réunion 1995 d'IBM est trop tôt
les scientifiques de bases de données relationnelles,
Chamberlin rappelé avoir une révélation
comme il a d'abord entendu Codd décrire son
modèle relationnel à un interne
séminaire.
« Codd avait un tas d'assez
requêtes compliquées « , a déclaré Chamberlin.
« Et comme je l'avais étudié des CODASYL
(La langue utilisée pour la requête
bases de données de navigation), je pouvais
imaginer comment ces requêtes auraient
été représentés en CODASYL par
des programmes qui étaient cinq pages
qui naviguer dans ce
labyrinthe de pointeurs et d'autres choses. Codd
trierait de les écrire comme
one-liners. ... (T) hey ne sont pas
compliqué du tout. Je dis: « Wow. »
C'était une sorte de conversion
expérience pour moi. Je compris ce que
la chose relationnelle était sur le point après
que. »
Je me souviens d'une transcription d'une interview intéressante au sujet de la mendicité de SQL mais ne peut pas le suivre vers le bas ..
Faites-le que la communauté wiki, s'il vous plaît.