Comment les SGBDR peuvent-ils être considérés comme une mode?

11

Ayant terminé mon niveau A en informatique en 2003 et obtenu un diplôme en informatique en 2007, et apprenant mon métier dans une entreprise utilisant beaucoup SQL, j'ai eu l'idée d'utiliser des bases de données relationnelles pour le stockage.

Donc, bien qu'il soit relativement nouveau dans le développement, j'ai été surpris de lire un commentaire (sur /software//q/89994/12436 ) qui disait:

[Certains développeurs] méprisent [SQL] et pensent que lui et RDBMS sont une mode

De toute évidence, un développeur compétent utilisera le bon outil pour le bon travail et ne créera pas de base de données relationnelle lorsque, par exemple, un fichier plat ou une autre solution de stockage est approprié, mais les RDBM sont utiles dans un grand nombre de circonstances, alors comment pourraient-ils être considéré comme une mode?

— StuperUser
source

1

Veuillez fournir le contexte - où avez-vous lu ce commentaire?

— Eran Galperin

8

Tout et n'importe quoi est considéré comme une mode par quelqu'un quelque part.

— Péter Török

Très vrai Péter, juste curieux de savoir pourquoi?

— StuperUser

5

Ces personnes ont généralement un autre paradigme qu'elles souhaitent promouvoir, ce qui va à l'encontre de l'idée de bases de données relationnelles. Par conséquent, les bases de données relationnelles sont mauvaises et doivent disparaître. Regardez les bases de données orientées objet, qui n'ont pas encore atteint la masse critique.

28

La clé est dans le R dans le SGBDR, qui signifie relationnel. Contrairement à la croyance populaire, cela ne signifie pas des relations entre les tables, mais plutôt le fait que chaque table est une relation au sens mathématique du mot .

Le modèle relationnel a des implications assez importantes. Vous devez modéliser vos données pour qu'elles correspondent aux relations et normaliser ce modèle . Si votre application est conçue comme un modèle orienté objet, le modèle relationnel ne convient pas. Ceci est largement connu sous le nom de non -correspondance d'impédance relationnelle-objet .

Une approche de cette non-concordance sont les ORM (mappeurs de relation d'objet), qui ont gagné en popularité. Mais ils ne sont pas la vraie solution, ils ressemblent plus à une solution au problème. Ils ne résolvent toujours pas vraiment le problème de la mise en correspondance de l'héritage de classe avec le modèle relationnel.

La vraie solution à l'inadéquation relationnelle-objet sont les OODBMS , qui n'ont malheureusement pas eu beaucoup de succès . PostgreSQL, qui est un OO / RDBMS hybride, prend en charge nativement les OOBD natifs. Un autre OODBMS est Zope Object DB , qui est construit en Python et dans une configuration typique utilise RDBMS comme moteur sous-jacent.

Une autre approche consiste à implémenter davantage de logique au niveau des applications ou des middlewares et à utiliser la solution NoSQL pour le stockage sous-jacent.

Ni OODBMS ni NoSQL ne sont "juste un fichier plat".

— vartec
source

2

@Daniel: il n'a certainement pas dit que le modèle relationnel était un problème qui avait besoin d'une solution; il a dit exactement ce que vous avez dit - si vous vous engagez à modéliser votre logiciel sur le paradigme orienté objet, alors le modèle relationnel est un problème.

— Carson63000

1

@Carson: Mes excuses, mais ce n'est pas ainsi que j'ai lu la réponse. @vartec dit: "La vraie solution est le OODBMS (qui n'a malheureusement pas eu beaucoup de succès)." Je ne suis respectueusement pas d'accord: je dirais que la vraie solution est de comprendre le modèle relationnel et de l'utiliser efficacement. OODBMS est une solution pour les pauvres quand vous devez utiliser les principes OO pour votre modèle de données, ce qui n'est certainement pas un cas universel.

— Daniel Pryden

1

@Daniel: Je pensais qu'il voulait dire qu'un OODBMS était la vraie solution, encore une fois, si vous vous êtes engagé à modéliser votre logiciel sur le paradigme orienté objet. Non pas que le modèle relationnel soit un problème en soi et que OODBMS soit la solution. Mais de toute façon, sans trop débattre lequel de nous a bien compris Vartec, je vais me retirer et le laisser clarifier s'il le veut. :-)

— Carson63000

1

@Daniel: Le contexte est important. Je dis avec célérité que ce modèle relationnel est un problème dans le contexte de la POO. Maintenant, à quel point la POO est universelle ou non, cela dépasse le cadre de cette réponse. Et btw. Les OODBMS ne sont pas la «solution du pauvre», les ORM le sont.

— vartec

1

@vartec: OK, je retire mon downvote. (Je ne peux pas le supprimer à moins que le message ne soit modifié.) Je pense qu'il serait préférable de préciser qu'il existe des solutions qui n'impliquent pas OO. Et oui, je suis d'accord qu'un ORM est pire encore qu'un OODBMS.

— Daniel Pryden

13

J'ai fait la déclaration que vous avez citée dans la question ci-dessus. Si vous voulez une citation pour vérifier mon hypothèse sur les développeurs sur ce site, alors lisez ma réponse à la question suivante et passez en revue la réaction négative des commentaires et des downvotes que j'ai reçus pour ce que je considère toujours comme une réponse acceptable.

Les programmeurs expérimentés devraient-ils connaître les requêtes de base de données?

J'ai fait l'affirmation que si une base de données SGBDR est utilisée, malgré Linq ou un ORM, un développeur devrait avoir une connaissance avancée de SQL.

C'était une affirmation très impopulaire, il semble en raison de divergences d'opinion respectables sur l'importance de SQL, à l'état d'esprit moins respectable que le SGBDR est intrinsèquement inférieur aux bases de données NoSQL comme MongoDB.

EDIT: Pour ajouter à ma demande, je citerai l'utilisateur SK-logic:

rappelez-vous juste que tout cet engouement RDBMS est une tendance relativement récente. Avant cela, nous avions une grande variété d'approches. Vous travaillez apparemment dans une jeune entreprise, aux côtés de développeurs de votre âge, et vous n'avez donc aucune chance d'être exposé aux approches de stockage plus anciennes et plus solides. Heureusement, cette tendance récente est déjà en déclin, et les bonnes vieilles méthodes sont de retour, rebaptisées «nosql».

— maple_shaft
source

Entièrement d'accord avec vous que les développeurs travaillant avec des bases de données doivent comprendre SQL pour pouvoir conceptualiser correctement une requête en termes de relations. Cependant, nous espérons que les Linq / ORM n'optimisent pas les requêtes sur l'abstraction d'une manière qui affecte les requêtes écrites avec le magasin de données à l'esprit.

— StuperUser

La seule raison pour laquelle quelqu'un dirait "cet engouement SGBDR est une tendance relativement récente" est de montrer à quel point leur barbe est grise. J'ai d'abord travaillé sur le type d'applications d'entreprise et d'entreprise que vous décrivez en 1995 - les bases de données relationnelles dominaient alors, elles dominent maintenant, elles ont dominé partout où j'ai travaillé au cours des 16 années qui ont suivi. Maintenant, évidemment, je ne suis pas aussi vieux que certains, mais quand je dis «relativement récent», je ne veux pas dire «au cours des vingt dernières années».

— Carson63000

Le problème est que de nombreux développeurs assimilent à tort RDBMS et SQL. SQL est un langage vraiment horrible selon les normes modernes. Il s'agit d'une implémentation imparfaite et incomplète d'un langage "relationnel" (SQL n'est pas vraiment relationnel du tout et cela fait partie du problème) qui n'a pas beaucoup évolué au cours des 30 dernières années. Beaucoup de gens utilisant SQL comprennent à peine le modèle relationnel - tout ce qu'ils savent, c'est SQL et ils supposent donc que le modèle relationnel est la cause de leur frustration.

— nvogel

@dportas, Sure SQL n'est pas parfait, mais il était si important pour chaque travail que j'avais que j'ai découvert à quel point la vie était devenue plus facile quand j'ai commencé à PENSER en SQL. Si vous me donnez un modèle relationnel et me posez une question en anglais simple, je peux vous écrire une "réponse" en SQL. Vous dites que «tout ce qu'ils savent, c'est SQL et donc ils supposent que le modèle relationnel est la cause de leur frustration», alors ils ne connaissent pas assez bien SQL. Pourquoi tout doit-il répondre au démonateur commun le plus bas de tous les temps, comme un programmeur indien qui gagne moins de 10 $ / heure avec une mauvaise éducation.

— maple_shaft

@maple_shaft, si vous pensez en SQL, alors vous pensez à certaines choses qui sont très fausses en termes relationnels. Ce qui devrait être encouragé, c'est que les développeurs comprennent les concepts de base comme le modèle relationnel au lieu de se concentrer sur des langages comme SQL. Si plus de gens comprenaient les concepts de base, alors SQL aurait peut-être déjà été remplacé par de meilleures choses.

— nvogel

9

mode :

une chose qui devient très populaire en peu de temps, puis qui est oubliée à peu près à la même vitesse. "

Les SGBDR existent depuis des lustres (au moins en termes de CS), donc quiconque a dit que cela voulait dire autre chose ou ne savait rien.

— l0b0
source

2

Je voulais dire autre chose, voir ma réponse ci-dessous.

— maple_shaft

La réponse est à programmers.stackexchange.com/questions/90024/…

3

Il aurait probablement été préférable d'utiliser un vrai dictionnaire plutôt que urbain.

— Aaronaught

Aaronaught - Et Princeton? "Un intérêt suivi d'un zèle exagéré." wordnetweb.princeton.edu/perl/…

— Shauna

3

L'alternative au SGBDR n'est pas seulement un fichier plat. Quand j'étais à l'école, OODBMS était la nouvelle chose et mon professeur avait raison quand il l'a étiqueté comme une mode. Vous devriez jeter un œil aux différents modèles et noter les tendances. J'ai vu une dépendance croissante à OLAP et je serais prêt à parier qu'un nouveau système multidimensionnel qui peut traiter les données plus rapidement approche à grands pas.

— Christopher Bibbs
source

"Vouloir être un nouveau" => "Veut-il parier un nouveau"?

— Binary Worrier

Oh certainement, utilisé un fichier plat comme exemple. C'est un bon lien vers les modèles DB.

— StuperUser

@Binary Oui et modifié pour le refléter.

— Christopher Bibbs

3

Le problème est que de nombreux développeurs assimilent à tort RDBMS et SQL. SQL est un langage vraiment horrible selon les normes modernes. Il s'agit d'une implémentation imparfaite et incomplète d'un langage "relationnel" (SQL n'est pas vraiment relationnel du tout et cela fait partie du problème) qui n'a pas beaucoup évolué au cours des 30 dernières années. Beaucoup de gens utilisant SQL comprennent à peine le modèle relationnel - tout ce qu'ils savent, c'est SQL et ils supposent donc que le modèle relationnel est la cause de leur frustration.

— nvogel
source

1

Sans contexte, il est difficile de déterminer qui / pourquoi l'affirmation selon laquelle les RDBM sont considérés comme une mode.

À court et moyen terme (5 à 10 ans) et je pense encore plus longtemps que ça ne va pas disparaître. Un RDBM fournit une méthode efficace et efficiente de stockage, de traitement et de récupération de données relationnelles, ce que la plupart des entreprises ont à offrir: clients / commandes, passagers / billets, etc.

Il existe d'autres alternatives telles que NoSQL qui semblent croître en popoularité avec les projets open source.

En tant qu'OLAP, il s'agit vraiment (dans mon esprit) de bases de données spécialisées conçues pour permettre à une entreprise de fournir des informations statistiquement opportunes et utiles sur une entreprise et d'exécuter des scénarios de simulation sur les données actuelles. Bien sûr, dans presque tous les cas, ces données actuelles provenaient d'un RDMB et ont été manipulées puis insérées dans la base de données OLAP.

— armitage
source

1

Les bases de données relationnelles sont une mode au même sens que la micro-informatique est une mode.

— Jeremy
source

1

La réponse simple est non. Les SGBDR ne sont pas une mode. Lorsque vous lisez quelque chose sur un site Web pour LinqPad, gardez à l'esprit que leur but est de vendre des licences pour leur produit.

— Tundey
source

La question est de savoir pourquoi cela serait considéré comme une mode, pas s'il s'agit de la rhétorique promotionnelle de LinqPad. La norme LinqPad est gratuite.

— StuperUser

La question lui vient de la lecture de la rhétorique promotionnelle de LinqPad. Je fais juste remarquer qu'il devrait prendre avec un grain de sel.

— Tundey

Non, ce n'est pas le cas, cela vient du commentaire de maple_shaft sur programmers.stackexchange.com/questions/89994/… . La copie de LinqPad a été prise avec une pincée de sel, mais je suis curieux de savoir si les développeurs sont d'accord avec l'une ou l'autre déclaration.

— StuperUser

Oui, la rhétorique promotionnelle de LinqPad était que l'écriture de SQL pour interroger un SGBDR était désuète, pas que les SGBDR eux - mêmes étaient désuets. Ils vendent une meilleure façon d'utiliser un SGBDR, pas une alternative à eux.

— Carson63000

@StuperUser et Carson63000: J'ai compris. Mon erreur.

— Tundey

0

Fad n'est pas le bon mot car ils sont là depuis très longtemps. Je pense que vous pourriez commencer à faire valoir que la technologie est très ancienne et qu'il serait peut-être temps de trouver la prochaine chose à faire - les architectures NoSQL peut-être

— bigtang
source

0

Le Wiki Def. of Fad , définit le terme "fad" comme suit: Un fad est toute forme de comportement qui se développe au sein d'une grande population et qui est suivie collectivement avec enthousiasme pendant une certaine période, généralement du fait que le comportement est perçu comme nouveau d'une manière ou d'une autre. On dit qu'un engouement "prend de l'ampleur" lorsque le nombre de personnes qui l'adoptent commence à augmenter rapidement. Le comportement s'estompe normalement rapidement une fois que la perception de la nouveauté a disparu.

Étant donné que les adeptes du SGBDR n'ont pas disparu rapidement et ne sont pas sur le point de disparaître dans de nombreuses années à venir (grâce à l'énorme pile d'applications de production l'utilisant), nous ne pouvons pas dire que c'est une mode. En fait, les concepts de base du SGBDR sont restés assez stables là où tant d'autres technologies ont changé (et continuent de changer) de façon spectaculaire.

Le concept du SGBDR (et de son principal véhicule, SQL) représente une étape technologique qui, comme beaucoup d'autres, peut être remplacée par de meilleures, c'est tout.

— Aucune chance
source