Raisons des différences SQL

Question

Pourquoi les distributions SQL sont-elles si non standard malgré une norme ANSI existante pour SQL ?Existe-t-il vraiment autant de différences significatives dans le fonctionnement des bases de données SQL ou s'agit-il simplement des deux bases de données avec lesquelles j'ai travaillé :MS-SQL et PostgreSQL ?Pourquoi ces différences apparaissent-elles ?

Answer 1

C'est une forme de "verrouillage furtif".Joel entre dans les détails ici :

• http://www.joelonsoftware.com/articles/fog0000000056.html
• http://www.joelonsoftware.com/articles/fog0000000052.html

Les entreprises finissent par lier leurs fonctionnalités commerciales à des fonctionnalités non standard ou étranges non prises en charge dans leur mise en œuvre, ce qui limite leur capacité à s'éloigner de leur fournisseur pour se tourner vers un concurrent.

D'un autre côté, c'est une vision assez myope, car toute personne dotée d'un demi-cerveau aura tendance à faire abstraction des éléments exclusifs, ou à éviter complètement le verrouillage, si cela devient trop flagrant.

Answer 2

La norme ANSI ne spécifie qu'un ensemble limité de commandes et de types de données.Une fois que vous dépassez ces limites, les implémenteurs se débrouillent seuls.Et certains concepts très importants ne sont pas du tout spécifiés, comme les colonnes à incrémentation automatique.SQLite sélectionne simplement le premier entier non nul, MySQL requiert AUTO INCREMENT, PostgreSQL utilise des séquences, etc.C'est le bordel, et cela ne concerne que les bases de données OSS !Essayez de demander à Oracle, Microsoft et IBM de décider collectivement d'une fonctionnalité délicate.

Answer 3

Premièrement, je ne trouve pas que les bases de données soient comme, par exemple, les navigateurs ou les systèmes d'exploitation en termes d'incompatibilité.Toute personne ayant quelques heures de formation peut commencer à effectuer des sélections, des insertions, des suppressions et des mises à jour sur n'importe quelle base de données SQL.Pendant ce temps, il est difficile d'écrire du code HTML qui s'affiche de manière identique sur chaque navigateur ou d'écrire du code système pour plusieurs systèmes d'exploitation.Généralement, les différences dans SQL sont liées aux performances ou à des fonctionnalités assez ésotériques.La principale exception semble être les formats et fonctions de date.

Deuxièmement, les développeurs de bases de données sont généralement motivés à ajouter des fonctionnalités qui différencient leur produit des autres.Des produits comme Oracle, MS SQL Server et MySQL sont de vastes écosystèmes qui se pollinisent rarement dans la pratique.Sur mon lieu de travail, nous utilisons Oracle et MySQL, mais nous pourrions probablement passer à 100 % Oracle en une journée environ si nécessaire ou souhaité.Je me soucie donc beaucoup des jouets brillants qu'Oracle nous offre à chaque version, mais je ne sais même pas quelle version de MySQL nous utilisons.IBM, Microsoft, PostgreSQL et les autres pourraient tout aussi bien ne pas exister en ce qui nous concerne.Disposer des fonctionnalités nécessaires pour attirer et fidéliser les clients et les utilisateurs est bien plus important que la compatibilité dans le monde des bases de données.(C'est le côté positif de la réponse « verrouillage », je suppose.)

Troisièmement, il existe des raisons légitimes pour lesquelles différentes entreprises implémentent SQL différemment.Par exemple, Oracle dispose d'un système multi-versions qui permet des lectures cohérentes très rapides et évolutives.D'autres bases de données ne disposent pas de cette fonctionnalité, mais sont généralement plus rapides à insérer des lignes et à annuler des transactions.Il s’agit d’une différence fondamentale entre ces systèmes.Cela ne rend pas l'un meilleur que l'autre (du moins dans le cas général), juste différent.Il ne faut pas être surpris si le SQL au-dessus d'un moteur de base de données profite de ses atouts et tente de minimiser ses faiblesses.En fait, il serait irresponsable de la part des développeurs de ne pas le faire.

Answer 4

John:La norme couvre en fait de nombreux sujets, notamment les colonnes d'identité, les séquences, les déclencheurs, les routines, les upsert, etc.Mais bien entendu, bon nombre de ces composants de normes peuvent avoir été mis en place plus tard que les premières mises en œuvre ;et cela pourrait être une raison pour laquelle la conformité aux normes SQL est généralement quelque peu faible.

Neall :Il existe en fait des domaines dans lesquels le standard SQL est en avance sur les implémentations.Par exemple, ce serait bien d'avoir CREATE ASSERTION, mais pour autant que je sache, aucun SGBD n'implémente encore d'assertions.

Personnellement, je pense que le caractère fermé de certaines normes ISO (comme la norme SQL) fait partie du problème :Lorsqu'une norme n'est pas facilement disponible en ligne, elle est moins susceptible d'être connue des responsables de la mise en œuvre/planificateurs, et trop peu de clients demandent la conformité parce qu'ils ne savent pas quoi demander.

Answer 5

C'est certainement un verrouillage efficace, comme le dit 1800.Mais par souci d'équité envers les fournisseurs de bases de données, le standard SQL rattrape toujours les fonctionnalités des bases de données actuelles.La plupart des bases de données dont nous disposons aujourd’hui concernent des lignées assez anciennes.Si vous remontez à l'origine de Microsoft SQL Server, je pense que vous trouverez Ingres, l'une des toutes premières bases de données relationnelles écrites dans les années 70.Et Postgres a été initialement écrit par certaines des mêmes personnes dans les années 80 pour succéder à Ingres.Oracle remonte à loin et je ne sais pas exactement où MySQL est entré en jeu.

La non-portabilité des bases de données est une mauvaise chose, mais cela pourrait être bien pire.