Intéressante certaine discutions, mais ou le sujet de base Open-Source .....
Intéressante certaine discutions, mais ou le sujet de base Open-Source .....
Oui, ou c'est comme si aujourd'hui, en 2020, on mangeait encore avec un couteau et une fourchette, vieux respectivement de 25 et 2 millénaires et qu'on l'on trouve déjà par ailleurs dans les musées.
Sachez que, contrairement à ce que vous dites, le SQL évolue. Par exemple, la norme de 1999 a introduit la possibilité de faire des requêtes récursives, qui pourrait répondre au besoin de votre site. et ce n'est qu'un exemple
Certes, il n'y a pas des évolutions majeures tous les jours, mais des évolutions pertinentes : c'est quand même stupide d'inventer la roue carrée pour la simple et unique raison que la roue ronde existe depuis plus de 5000 ans et est donc has been et inefficace
Bizarrement en tant que développeur, de SQL 1999 (ou SQL 3) je retiens surtout l'ajout des fonctionnalités orientées objet (en fait relationnel/objet), or je n'ai jamais vu un DBA produire un schéma avec héritage.
Sans compter qu'Oracle ne supporte même pas l'héritage de tables, pourtant clairement inscrit dans SQL 3
Résultat, les ORM ne peuvent pas utiliser l'héritage de table non plus étant donné qu'en se voulant indépendants du SGBD, ils prennent toujours le plus petit dénominateur commun, un peu comme AWT en Java qui ne contenait que des composants existant sur toutes les plateformes et renonçaient donc à des composants importants tels qu'une combobox.
Notez que l'héritage de tables et de type, ce n'est pas la même chose. La première implique la seconde. Oracle n'implémente que la seconde.
A ce niveau, PostgreSQL est plus proche de SQL 3 qu'Oracle du coup. Alors évidemment certains vont dire que l'héritage entre tables est utilisé pour le partitionnement, sauf que moi je l'utilise pour bien d'autres choses et qu'entre temps PostgreSQL a un nouveau système de partitionnement qui n'a rien à voir avec l'héritage, ce qui permet de réserver ce dernier à ce qui aide vraiment les programmeurs.
La prise en compte du standard SQL est à mon avis beaucoup plus difficile que celle par exemple du HTML/CSS (qui reste sans aucun doute au dessus de mon niveau). Les acteurs prennent donc avant tout ce qu'ils trouvent le plus pertinent. Et même en tant que DBA.
Car il faut parvenir à ajouter les nouveaux éléments non seulement sans casser le reste, mais en garantissant toujours des performances dignes de ce nom, en particulier au niveau du moteur d’interprétation SQL et de calcul du plan de la requête, des index,....
Une roue carrée serait adaptée sur des routes ayant la forme d'un toît en tôle ondulée. Tant que de telles routes n'existent pas la roue ronde convient parfaitement, mais qui sait si on aura pas un jour de très bonnes raisons de faire autrement.
A l'inverse la roue ronde serait inadaptée sur des routes qui ne sont pas à peu près planes
Plusieurs usages, plusieurs besoins, plusieurs produits. Le mieux est de choisir ce qui est adapté, pas de copier bêtement le voisin.
Sans doute, mais puisque certains ici viennent nous expliquer que les SGBD commerciaux ont plein de fonctions en plus par rapport aux SGBD libres, je voulais surtout montrer que parfois, l'inverse est vraie aussi.
S'il n'y avait que cela ! Et même avec cela il y a des bugs sous PG toujours pas résolus...
https://www.developpez.com/actu/2457...u-FOSDEM-2019/
Pour rappel aucune solution, juste un correctif qui permet de mieux mettre en évidence que le système n'arrive pas à faire des écritures !!!
A +
Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
* * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *
Les SGBD OO ont disparu par darwinisme. Il est possible d'indexer des données scalaires atomiques par un simple tri des valeurs organisées par dichotomie (arbre de recherche). Ceci est déjà plus difficile pour des éléments à plusieurs composantes (exemple indexation spatiale, moins efficace car 2 cordonnées). C'est impossible pour des objets ayant de multiples attributs qui ne sont pas situé au même niveau hiérarchique... Tout simplement !
Et si les performances d'un SGBD OO sont inférieur à un simple accès à un fichier ISAM, alors il n'y a aucune intérêt à payer cher quelque chose d'inutilisable !
A -
Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
* * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *
Donc selon toi les indexes couvrant plusieurs colonnes, comme ici, sont inefficaces?
Pourtant je vois un moyen très simple de le faire, c'est de créer un index fonction.
Si je considère l'accès au champ x.y.z comme une fonction, alors cette fonction est déterministe et donc éligible à l'indexation.
Le seul cas où je pourrais éventuellement voir un problème, c'est si certains champs peuvent exister pour certaines lignes et pas d'autres, ce qui pourrait arriver par héritage.
Au passage, les SGBD relationnels ont déjà des attributs hiérarchiques, par exemple les RECORD en Oracle, qui peuvent eux-même contenir d'autres RECORD, ou l'usage de REF. Et il y a aussi l'héritage de type. Mais peut-être qu'on ne peut pas les indexer?
Note que je fais ici des recherches pour pouvoir citer Oracle, que j'utilise rarement, pour que tu ne puisses pas venir dire que j'ai sorti du chapeau une fonction spécifique à un SGBD que je connais mieux. Mais je n'ai pas lu tout ce que j'ai trouvé en détail, donc si tu me dis que tout ce que j'ai trouvé est inefficace, je peux le croire.
Pas besoin que le type soit scalaire pour ça, il suffit qu'il ait une relation d'ordre total correctement définie.
En programmation on crée souvent des arbres de recherche en mémoire, sans forcément y penser (par exemple, les types TreeMap et TreeSet en Java). Si tu regardes la spécification de ces types, tu verras qu'on n'impose pas que la clé soit scalaire, on impose seulement qu'elle ait une relation d'ordre valide.
Et quand bien même, comme tu parles de coordonnées comme un exemple de donnée scalaire non atomique, je vois bien un moyen de les rendre scalaires, au moins pour les nombres entiers: utiliser un entier long pour coder l'abscisse sur les octets de poids fort et l'ordonnée sur les octets de poids faible. Au final le type entier long est un scalaire atomique. Avec des flottants on pourrait jouer sur les octets aussi mais plus difficilement, c'est vrai.
Heureusement d'ailleurs, parce qu'au sens strict, on pourrait considérer que le type "chaîne de caractères" n'est pas vraiment un scalaire atomique dès lors qu'il a une longueur variable. Pourtant il n'y a aucun problème à indexer des chaînes car on a déjà un ordre qui était utilisé bien avant l'invention de l'informatique: l'ordre alphabétique!!!
Évidemment qu'un index peut porter sur plusieurs colonnes !
Rien à voir avec la problématique des données spatiales.
Si tu crées un index (X,Y), comment fais-tu pour trouver tous les points qui sont à moins de 5 km d'un point donné ?
Pas d'autre solution que de lire l'ensemble des points !
Si tu crées un second index (Y,X), tu doubles la quantité de données indexées (donc le stockage, la mémoire et les temps de mise à jour sont rallongés d'autant).
Ensuite, il va falloir faire du bounding box à la main en complexifiant le traitement de recherche afin de bénéficier de l'un ou l'autre des index... en fonction des données lues... compliqué.
Et là je parle de chercher des points à une distance donnée d'un autre point... Maintenant, à partir du tracé des frontière d'un pays (polygone de quelques milliers de sommets) trouve l'ensemble des points qui sont contenus dedans.
Elle est là, la problématique d'indexer des données non scalaires.
Là on parle de deux point... je te laisse imaginer avec des objets complexes (sans parler de polymorphisme ou d'héritage, on n'en est pas encore là).
Sinon, le RECORD d'Oracle est à mon sens un truc qui doit commencer à dater et doit apporter plus de lourdeur qu'autre chose.
Cependant, Oracle et SQL Server permettent d'utiliser des représentations d'objets (XML ou JSON notamment) avec tout ce qu'il faut pour accéder aux attributs des objets.
Sous SQL Server les index XML s'en sortent à peut près, mais restent très en deçà des performances qu'on peut espérer en stockage proprement les objets sous forme de lignes et de colonnes dans des tables. Pour ce qui est de JSON à priori pas d'index (je trouve ça un peu con, cas sorti de la syntaxe XML et JSON sont identiques, donc c'est surprenant que Microsoft n'ait pas étendu l'indexation du XML aux colonnes JSON).
https://docs.microsoft.com/fr-fr/sql...l-server-ver15
https://docs.microsoft.com/fr-fr/sql...l-server-ver15
On ne jouit bien que de ce qu’on partage.
Si un point B(xB,yB) est à moins de 5 kilomètres de A(xA,yA) alors |xB - xA| < 5 km et |yB - yA| < 5 km, car le carré de 10 km autour de A englobe entièrement le cercle de 5 km autour de A. Donc si c'est pour trouver les points à une distance donnée, j'aurais plutôt tendance à créer deux indexes, 1 pour l'abscisse et un pour l'ordonnée, à filtrer sur l'intervalle (-5, +5) et ensuite regarder parmi les points restants ceux qui sont effectivement dans le cercle.
Merci, tu confirmes en fait ce que je disais: les affirmations de SQL Pro disant qu'il est difficile d'indexer plusieurs colonnes ou des colonnes contenant des sous-champs sont absurdes, surtout à l'heure où on utilise de plus en plus souvent des colonnes JSON ou XML. Avec PostgreSQL je peux déjà indexer un champ dans XML ou dans JSON, sur les autres serveurs je pensais que c'était déjà le cas mais je suppose que ça viendra.
Les index ne se combinent pas.
Si tu crées un index I qui range tous les points dans un arbre binaire de recherche en triant sur l'abscisse, alors tu pourras faire une requête performante qui trouve tous les points avec une abscisse entre xA - 5 km et xA + 5 km. Cela correspond à deux recherches en O(log n) dans l'arbre binaire pour trouver les deux bornes. Entre les deux nœuds, il n'y aura que les points avec la bonne abscisse.
De même, si tu crées un index J qui range tous les points dans un arbre binaire de recherche en triant sur l'ordonnée, alors tu pourras faire une requête performante qui trouve tous les points avec une ordonnée entre yB - 5 km et yB + 5 km. Cela correspond à deux recherches en O(log n) dans l'arbre binaire pour trouver les deux bornes. Entre les deux nœuds, il n'y aura que les points avec la bonne ordonnée.
Par contre, avec tes deux index, pour trouver tous les points à 5 km de A, soit on n'utilise que I pour parcourir tous les points avec la bonne abscisse puis on filtre selon la distance, soit on n'utilise que J pour parcourir tous les points avec la bonne ordonnée puis on filtre selon la distance. Tu ne pourras pas aller plus vite.
Dans la page Spatial Indexes Overview de la doc de SQL Server, avec les index spatiaux, les points sont rangés dans des grilles qui sont elle-même rangées dans des grilles, etc.
À part ça, pour les cas que j'ai connus, je suis entièrement pour une architecture dans laquelle le code applicatif ne passe que par des vues et des procédures stockées. Le code applicatif pourrait quand même utiliser un ORM pour générer des requêtes SQL, mais ces requêtes n'auraient pas accès directement aux tables physiques.
Mettre cette couche d'abstraction est juste un exemple d'application de la programmation modulaire : on isole les dépendances envers l'implémentation pour que l'ensemble soit plus facile à maintenir et plus rapide à faire évoluer.
Les développeurs doivent avoir le droit de générer des requêtes plus compliquées que SELECT * FROM my_view. Il ne faut pas déconner non plus.
Ah il est certain que j'aurais une de ces productivités si je devais demander l'aval du sain dba chaque fois que j'ajoute un modèle dans mon app
Ça, ce n'est pas un problème technique, mais un problème organisationnel de l'entreprise.
Remarque : je n'ai travaillé que dans des PME où c'étaient les développeurs qui s'occupaient des données. Naïvement, je m'attends à ce qu'un DBA ait un statut similaire à celui d'un développeur, responsable aussi de la vitesse des développements et du bon fonctionnement de l'application, mis à part qu'il a plus de compétences en bases de données et moins en développement pur. Comment ça se passe, dans une boîte normal ? À lire certains postes sur ce forum, on a l'impression que les DBA sont épargnés par les contraintes de délai.
Tu peux te retrouver à indexer le couple (x,y) et ça s'avère plus efficace au niveau PostGIS pour rechercher des égalités strictes que de s'appuyer sur un indexe spatial (GIST).
Les grilles, c'est pas franchement la rolls de l'indexation spatiale (définition d'un pas, connaissance bbox globale à priori, taille de l'indexe,...). PostGIS s'appuie sur des RTree pour indexer les boites englobantes (voir Spatial Indexing) (il n'y a pas ce genre de méthode d'indexation dans SQL Server?)
Je ne comprend pas trop la fin... Avec PostgreSQL, tu peux https://www.postgresql.org/docs/9.1/...ressional.html. Dès lors, si le SGBD sait indexer row.att1 et f(row), il peut indexer row.properties.attribut_utilisateur.
C'est pratique pour couper la poire en deux entre des tables rigides et des documents façon MongoDB lorsque tu veux permettre à des utilisateurs d'ajouter leurs attributs par exemple...
Pour revenir au sujet de départ, il y a toujours quelqu'un qui paie directement ou indirectement pour un logiciel de base de données open source. Il est intéressant de s'interroger sur les motivations du côté des utilisateurs et des fournisseurs. Si on prend le cas de PostGIS qui justifie selon moi l'utilisation de PostgreSQL pour pas mal d'acteur du monde du SIG :
- Quand le gros de la valeur ajoutée est dans son produit fini, il n'est pas déraisonnable de payer l'ajout d'une fonctionnalité à PostGIS pour ne payer une licence sur un SGBR non libre ou être le seul à maintenir un algorithme de calcul géométrique.
- Quand on développe un logiciel type SIG, inclure une dépendance à un SGBD payant fait monter la facture des clients et rend non compétitif face à ceux qui mettent en commun leurs efforts autour de PostGIS et se concurrencent sur le développement des surcouches et interfaces.
- Quand on est un contribuable, il peut être rentable de financer indirectement PostGIS via des projets de recherche s'appuyant sur ce dernier, plutôt que de n'avoir aucune alternative au paiement d'une licence de SGBD par processeur dans chaque organisation exploitant des données spatiales.
- Quand on est développeur, il peut être aussi intéressant de se rémunérer en donnant des formations sur PostGIS et en développant des fonctionnalités à façon ou en surcouche, qu'en étant salarié d'une boite fournissant un SGBD payant.
Après, des bugs, il y en a sûrement... La différence entre l'opensource gratuit et le payant fermé en la matière, c'est que lorsqu'un bug pose vraiment des problèmes, on a d'autres options que se battre à faire admettre au fournisseur que le bug existe et qu'il faut le traiter : Payer un indépendant ou mettre les mains dans le cambouis.
Il faut toujours viser la lune, car même en cas d'échec on arrive dans les étoiles. O.Wilde
Mes Articles/Critiques :
Merise - Guide pratique
PHPExcel
PostgreSQL : Administration et exploitation d'une base de données
PostgreSQL : Entraînez-vous à créer et programmer une base de données relationnelle
Je pensais qu'il était possible de créer un premier ensemble avec l'index I et un deuxième avec l'index J, et de calculer l'intersection des deux. Mais je viens de faire le test avec PostgreSQL et EXPLAIN me confirme qu'un seul index est utilisé. Dont acte.
Par contre:
Non, il n'y a qu'une seule recherche: une fois que tu as trouvé le minimum (x - 5) tu peux parcourir l'arbre en sens inverse, il est trié correctement jusqu'à (x + 5). En plus de cela souvent les bases de données utilisent des arbres B+ qui ne sont plus tout à fait des arbres, leurs feuilles les plus profondes sont liées comme une liste triée (voir ici par exemple) justement pour permettre de faire des recherches par intervalle.
Maintenant je reviens au problème initial, j'ai continué d'y réfléchir.
Un index (X,Y) c'est un arbre qui est construit en fonction de la relation d'ordre (a,b) -> (xA < xB ou xA = xB et yA < yB) : on indexe d'abord x et en cas de valeur identique, on se base sur y.
Avec une requête telle que where x > -5 and x < 5 and y > -5 and y < 5, l'index sera utilisé, là encore je viens de vérifier avec Postgres.
A part l'usage de deux indexes, ma méthode reste donc valable, mais encore faut-il comprendre qu'elle est en deux étapes. On reste d'accord que la requête précédente ne donne pas la liste des points qui sont dans le cercle mais dans le carré; par contre, tu appelles la fonction de calcul de distance seulement sur les résultats de cette requête, donc tu exclus au moins tout ce qui sort du carré et c'est déjà pas mal!
Donc pour la deuxième phrase: non, pas besoin d'examiner tous les points.
En fait c'est la même chose: tout polygone est quand même dans un rectangle. Donc non l'index ne permet pas de répondre directement à cette question, mais il permet au moins de réduire le champ de recherche et ensuite tu appelles la fonction disant si on est à l'intérieur sur sensiblement moins de points.
Je travaille actuellement dans le monde de la traduction et on a un problème similaire pour trouver des phrases similaires (le but étant de s'inspirer d'anciennes traductions pour assurer la cohérence dans le temps). La fonction qui calcule la distance entre deux phrases est en O(N²) et aucun index ne changera cela. En revanche, en utilisant certains découpages de chaînes on peut créer un index qui élimine une grosse partie des phrases qui n'ont aucune chance de rester proches de la phrase en cours. Mais un deuxième filtrage reste nécessaire ensuite.
Et au passage comme ils ont été cités, pour ce travail j'utilise des indexes GiST dans PostgreSQL, mais j'avoue avoir juste regardé les résultats, je n'ai pas cherché en détail leur mode de fonctionnement.
Conclusion: les indexes ne peuvent pas tout, mais il faut penser à ne pas toujours vouloir tout faire en une seule requête.
Mais encore? Je veux bien le croire mais dit comme ça ce n'est pas très convainquant, il faudrait quand même un peu plus de détails!
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Partager