Quelles sont, selon vous, les lacunes de SQL et quels changements y apporteriez-vous?

Avez-vous rencontré des lacunes, des limitations ou des défauts lors de l’utilisation de SQL?

Les tâches simples à réaliser avec d’autres langages non-SQL sont si compliquées voire impossibles à faire avec SQL!

Voici un bon exemple

Pouvez-vous me fournir des exemples de problèmes rencontrés ou de cas où, par exemple, une requête SQL nécessitait des constructions complexes? Un piège dans lequel les gens tombent est de penser que la solution désirée doit s’inscrire dans une seule instruction SQL.

Pouvez-vous suggérer des améliorations pour rendre SQL plus puissant et moins compliqué? Exemple: PSM

Quelle implémentation SQL vous semble la plus robuste?

Quelles fonctionnalités d’un environnement non-SQL aimeriez-vous voir implémentées en SQL? ..

Supposons que SQL n’existe pas, que feriez-vous pour manipuler des données? ..

Personnellement, j’ai un faible pour les bases de données CODASYL, dans lesquelles vous parcourez des ensembles de données pour accéder à des éléments de données connexes … peut-être parce que ma première expérience en bases de données était le SGBD DECs. La possibilité de localiser un dossier parent, puis de faire marcher un groupe d’enfants était simple à utiliser; et les relations explicites entre les jeux de données intégrés à la structure de firebase database sous-jacente sont quelque chose qui manque cruellement dans les bases de données relationnelles … et avant que quiconque ne le suggère, les clés étrangères sont une ombre pâle et unidimensionnelle de cette relation.

Les complexités des jointures internes / externes / droites dans SQL deviennent inutiles, car la structure du jeu de données maintient les relations entre différents jeux d’enregistrements (tables), ce qui vous permet d’accéder uniquement aux enregistrements du jeu de données associés. Rechercher une commande et parcourir le jeu de données OrderLine ne renvoient que les lignes de commande qui faisaient partie de cette commande, sans qu’il soit nécessaire de formuler une seconde requête pour extraire cette série de lignes de la table entière des lignes de commande pour toutes les commandes.

L’inconvénient était que presque toute la conception devait être faite à l’avance … une fois que la structure de la firebase database a été conçue, elle était pratiquement fixe, difficile à changer … par rapport au SGBDR où il est beaucoup plus facile d’append de nouvelles tables à tout moment …. pas particulièrement adapté à un monde de RAD / Agile / XP / Scrum.

Maintenant, si seulement quelqu’un pouvait créer un système de firebase database où la structure était aussi flexible et facile à modifier qu’un SGBDR, avec toute la simplicité d’access aux données d’une firebase database CODASYL.

Les bases de données OLAP sont une autre excellente alternative au SGBDR, où les données peuvent facilement être structurées en un cube à n dimensions, où une requête vous permet de “trancher et dés” le cube, en extrayant rapidement des segments de données. Ma première introduction à OLAP a été Oracle Express, qui utilise (malheureusement) son propre langage de requête propriétaire plutôt que le MDX standard de facto. Cependant, toutes les données ne peuvent pas être facilement adaptées à une structure en “cube”. Par conséquent, elles ne conviennent que pour certains types d’applications, même si presque toutes les applications d’exploration de données sont bien adaptées.

SQL en général présente de sérieuses lacunes en tant que langage de firebase database. Quelques-uns des problèmes sont:

  • Lignes en double (multi-ensembles plutôt que modèle basé sur les ensembles)

  • Les valeurs nulles et la logique des trois valeurs ajoutent de la complexité, de l’ambiguïté et des résultats incohérents sans append de pouvoir expressif au langage

  • La syntaxe de l’instruction SELECT est beaucoup plus détaillée et complexe que l’algèbre relationnelle

  • Le manque de prise en charge pour les affectations multiples signifie que la prise en charge de l’intégrité référentielle et des contraintes en général est sévèrement limitée.

Deux exemples de problèmes de requête plus spécifiques rencontrés en SQL:

  • Pas d’équivalent simple pour la fermeture transitive en SQL. La sélection à partir de structures de relation d’adjacence nécessite donc l’utilisation de code de procédure, de curseurs ou de la syntaxe de requête non intuitive et difficile à optimiser.

  • L’absence d’inheritance de clé signifie que les interfaces de requête SQL renvoient invariablement de simples tables bidimensionnelles, ce qui constitue un inconvénient majeur pour les requêtes de type OLAP (Decision Support) insortingnsèquement n-dimensionnelles.

Des améliorations? Je ne crois pas que des améliorations utiles auraient du sens, car la résolution de ce qui précède changerait le langage de manière si radicale qu’il serait inutile de prétendre que ce serait du SQL. Je crois que la meilleure voie à suivre consiste à développer des langages entièrement nouveaux et véritablement relationnels. Date et le modèle D de Darwen étant le successeur le plus évident de SQL ont déjà conduit à un certain nombre de nouvelles implémentations de langages relationnels.

Pour append aux excellentes réponses de @dportas, les grandes «opportunités manquées» en SQL, c’est que les extensions temporelles proposées, connues sous le nom de TSQL2, n’ont jamais été intégrées au standard SQL. Par conséquent, il est extrêmement difficile d’obtenir des bases de données temporelles même en utilisant Full SQL-92. Par exemple, une affectation multiple serait un avantage lorsque, par exemple, une suppression séquencée dans une table d’états valides requirejs quatre instructions (un INSERT , deux UPDATE et un DELETE ). Si vous considérez que la plupart des fournisseurs ne prennent pas en charge les fonctionnalités SQL-92 (par exemple, SQL Server DEFERRABLE contraintes DEFERRABLE , Oracle n’a pas de réponses incomplètes dans les contraintes CHECK , etc.), il est presque impossible d’y parvenir sans le «pire» type de code procédural.

Du sharepoint vue d’un langage de manipulation de données, SQL présente quelques faiblesses:

  1. Il n’y a pas de méthode SQL standard pour utiliser des expressions régulières. Les contraintes de données sont souvent exprimées sous forme de regex et il serait très utile de disposer d’un langage de regex standard en SQL. Je sais que SQLite vous permet de créer votre propre moteur de regex, et je suis sûr que d’autres bases de données le font aussi, mais une firebase database standard serait bien.
  2. SQL nécessite un langage de programmation impératif au sein de SQL, avec des constructions de langage telles que des variables et des affectations de variables, des fermetures lexicales et des iterators.
  3. SQL a besoin d’un moyen standard pour exprimer des fonctions définies par l’utilisateur pouvant être utilisées dans des requêtes.

C’est ce que je pense qui l’aiderait en tant que langage de manipulation de données relationnel. Pour les autres types de données, SQL n’est pas assez bon.

Réponses fantastiques, dportas 🙂

Bien que je ne souhaite pas autant de glamour, je souhaite quelque chose dans le standard SQL, mais l’algorithme de résolution de conflit de contraintes “INSERT OR UPDATE”. MySQL et SQLite l’ont implémenté comme des extensions du standard SQL .

Cette OMI doit être une fonctionnalité insortingnsèque du moteur de firebase database. Sinon, vous vous retrouvez avec des problèmes tels que:

 IF (record_exists) THEN -- update record ELSE -- insert new record 

Ce qui semble banal, mais ça

  • favorise les mauvaises habitudes comme le copier / coller du bloc de code, qui
  • introduit des bugs et
  • juste perdre votre temps, plusieurs fois.
  • Il ajoute également des points négatifs à la maintenabilité.

Deux requêtes peuvent être facilement remplacées par une:

 "Insert OR Update Table (field = value) Where ID = @ID" 

On se sent tellement plus naturel 🙂

Avez-vous rencontré des lacunes, des limitations ou des défauts lors de l’utilisation de SQL?

Plusieurs: http://c2.com/cgi/wiki?SqlFlaws

Pourriez-vous accomplir la même tâche facilement avec un autre langage DML ou de programmation?

Je suis sûr que la réponse est oui. Le troisième manifeste décrit ce que nous devrions utiliser à la place de SQL: Tutoriel D

Pouvez-vous me fournir des exemples de problèmes rencontrés ou de cas où, par exemple, une requête SQL nécessitait des constructions complexes par opposition à des constructions simples dans autre chose?

Oui: prenons, par exemple, le changement de nom de colonnes en SQL. Supposons que j’ai une table avec ces colonnes: a, b, c, d, e, f, g, h, maintenant, disons que je veux renommer la colonne a en “X”. en SQL je dois écrire:

 SELECT a as X,b,c,d,e,f,g,h,i FROM SomeTable 

Dans le didacticiel DI, écrivez seulement:

 SomeTable RENAME ( a AS x) 

Ou voyons l’inverse, quelle est l’équivalent de cette requête du didacticiel D:

  SomeTable REMOVE (e) 

Eh bien, c’est (difficile de trouver le “e” manquant … non?):

 SELECT a,b,c,d,f,g,h,i FROM SomeTable 

Ou simplement, dites-moi, avec quel code est-il plus facile de comprendre l’intention du développeur avec ceci:

 SELECT a as X,c,d,e,f,g,h,i, g+h as z from SomeTable 

ou avec ceci (c’est la même requête!):

 SomeTable RENAME (a AS X) REMOVE (b) ADD (g+hz) 

Voir? SQL est imparfait jusqu’à la base! Ou simplement, essayez simplement d’écrire select * à partir d’un appel de procédure stockée . En fonction de la firebase database, il pourrait ne pas fonctionner

Pouvez-vous suggérer des améliorations pour rendre SQL plus puissant et moins compliqué?

Beaucoup, remplacez-le par quelque chose comme Tutorial D, ou Dataphor

Quelle implémentation de produit SGBDR / SQL vous semble la plus robuste?

PseudoRDBMS robuste? Oracle, DB2 et SQLServer. RDBMS robuste? Il n’y en a pas. Peut-être que Dataphor ou Rel deviendront les premiers … tous les autres n’ont pas le droit de s’appeler “relationnels”

Quelles fonctionnalités d’un environnement non-SQL souhaiteriez-vous voir implémentées en SQL?

Mon rêve est de voir un jour une implémentation correctement relationnelle … mais pour le moment, je serais heureux si une firebase database implémentait la norme SQL (aucune ne le fait)

Supposons que SQL n’existe pas, que feriez-vous pour manipuler des données? ..

Je vais lire le troisième manifeste et le mettre en œuvre. Vous pouvez également utiliser DataLog ou Genexus pour vous donner l’ indépendance du chemin d’access . Genexus vous donne même la normalisation par synthèse , bien au-delà de ce que SQL peut faire.

Ou, plus récemment, les requêtes ODATA (mais, malheureusement, ODATA partage certaines des faiblesses de SQL)