Comparaison des performances de SIG
PostGreSQL/PostGIS vs SQL Server Spatial

Passons sur le choix du benchmark : le TPC-C qui date de 1992 (soit 23 ans…) est constitué d’une base de données qui comporte 9 tables et dont on peut trouver le détail à l’URL :
http://www.tpc.org/tpc_documents_current_versions/pdf/tpc-c_v5-11.pdf. Qui aujourd’hui utilise en production une base composée au plus de 9 tables ? En revanche il existe un benchmark plus moderne, le TPC-E composé de 33 tables nettement plus réaliste !

TUNING DES OS

À la page 10 dudit benchmark on trouve le paragraphe 3.3.1 (Operating System) qui montre comment à été optimisé Linux.

On y voit clairement que seul l’OS Linux a été optimisé. Quelles optimisations ont été faites pour Windows ? Aucune !

Or il est bien évident qu’une installation standard de Windows pour héberger SQL Server n’est pas optimale sans certains réglages :
– désactivation des services inutiles (ce qui a été fait pour Linux et pas pour Windows)
– désactivation du système d’économie d’énergie (qui n’existe pas sous Linux.. pas écolo les linuxiens !)
– activation de Turbo Boost
– activation de l’Instant File Initialization pour le service SQL Server
– activation du Lock Page in Memory pour SQL Server
…

TUNING DES SGBDR

À la page 11 figure le paragraphe 3.3.3 (Database) qui montre comment a été optimisé PostGreSQL.

On y voit clairement que seul PostGreSQL a été optimisé. Red Hat revendique même sa tromperie : « …no specific SQL Server tuning was performed » !

Or il est bien évident que plusieurs optimisations sont nécessaires :
– la ventilation du stockage des fichiers de données de la base tempdb (objets temporaires) en autant de fichiers d’égales longueur que de CPU (donc au moins 2);
– le dimensionnement correct des fichiers de la base de données à 40 Go pour les données et 10 Go pour les transactions avec à nouveau au moins 2 fichiers pour les données
– la limitation de la RAM utilisée par SQL Server à au moins 44 Go (max server memory);
– la limitation du parallélisme des requêtes à 4 (du fait que le serveur présente 2 CPU Quad Core et 4 LUN par agrégats RAID) et hausse du seuil de déclenchement à 12 (cost threshold for parallelism);
– le positionnement du paramètre « optimize for ad hoc workloads » à 1 sinon les plans de requête ne sont pas mis en cache !
– l’élévation du délai de report des écritures physique de données (checkpoint), paramètre « recovery interval », à 60 minutes pour coller au paramètre « checkpoint_timeout  » positionné à 1 heure dans PostGreSQL (un délai tout à fait anormal entre nous, car cela pourrait s’avérer dangereux en production…)
…

POSTGRESQL PLUS

Très discrètement, le document montre que la version testée de PostGreSQL n’est pas la version gratuite Open Source, mais la version payante fabriquée par EntrepriseDB et nommée « PostGreSQL PLUS.
Nous n’avons pas pu obtenir le prix d’une telle version directement sur le site d’EntrepriseDB, mais sur un autre document, provenant probablement du gouvernement britannique ce prix apparait être 3 265 £ par CPU (socket), soit environ 4 700 €…
En comparaison, SQL Server 2008 R2 version Web, suffisante pour ce benchmark, coute 4 246,41…

LES RÉSULTATS

Comme on s’y attendait, avec un tel paramétrage, PostGreSQL bât haut la main SQL Server ! haut la main ? pas si sûr…

Il faut vraiment y aller à la loupe pour voir la différence. En mesurant après impression avec une règle, j’ai constaté un écart relatif de 3 à 5 % mesuré sur les entrées 40 et 140 de l’histogramme…

Bref, il est très probable qu’avec les réglages manquants pour Windows et SQL Server, Red Hat n’aurait jamais publié un tel benchmark tant il aurait été défavorable à PostGreSQL fût-il PLUS !

Ce qui me navre c’est que je croyais naïvement que Red Hat était une entreprise sérieuse !

***

L’entreprise SQL Spot
Le site web sur le SQL et les SGBDR

1 – cycle de production de PostGreSQL

 »
PostgreSQL stabilise et distribue une nouvelle version majeure de sa base de données chaque année.
[..]
Bien sûr, très peu de projets industriels peuvent se permettre de revoir leur architecture, leurs procédures et leur intégration SQL chaque année, et même dans le milieu très dynamique des services web cela n’arrive quasiment pas.Aussi les versions de PostgreSQL sont-elles maintenues pendant au moins cinq ans, les versions courantes de PostgreSQL sont donc au nombre de 5 à 7 selon les moments de l’année.
 »

Mon commentaire sur ce point :

Vous affirmez que le rythme des versions de PostGreSQL est très élevé… Une toutes les 6 mois à vous lire…
Faisons la comparaison…

Rythmes des versions de SQL Server

Soit 14 versions en 6 ans, plus de 2 par an dont 4 versions majeures… Rien à envier donc à PostGreSQL !
PostgreSQL n’a eu dans cette même période que :
2 versions majeures : la 8 en 2005 et la 9 en 2010
En tout, de 2008 à 2015 il y a eu 7 versions mineures/majeures, soit 2 fois moins que SQL Server…

En sus les versions de SQL Server sont maintenues par le support Microsoft de manière publique avec un décalage de 2 versions majeures (soit 6 ans) et de manière payante (support étendue) près du double…

Fin du support étendu des différentes versions :

2) Avancées technologiques

 »
Il existe ensuite de nombreux points techniques donnant un avantage très net à PostgreSQL, soit qu’il s’agisse d’innovations technologiques issues de la recherche, telles les « Serializable snapshot isolation » (ou SSI)…
 »

Mon commentaires sur ce point :

Vous parlez du niveau d’isolation en invoquant le « Serializable snapshot isolation »
Mais PostGreSQL est toujours incapable d’utiliser le niveau d’isolation normatif READ UNCOMMITTED qui permet d’éviter tout verrou.
SQL Server dispose depuis la version 2005 du niveau d’isolation SNAPSHOT en 2 modes différents :
SNAPSHOT et READ COMMITTED SNAPSHOT
En sus dans SQL Server il est possible de changer le niveau d’isolation à tout moment, y compris au sein même d’une transaction, ce qui n’est pas le cas dans PostGreSQL. Ainsi, le code suivant marche sous SQL Server et provoque une erreur dans PostGreSQL :

3) Facilité de codage

 »
Bénéficier de PostgreSQL pour résoudre cet ensemble de problème permet de ne pas avoir à les résoudre à nouveau dans votre application (quel jour serons-nous dans trois mois ? SELECT to_char(date ‘today’ + 3 * interval ‘1 month’, ‘Day’); est sûrement plus facile à utiliser que n’importe quel autre code, les développeurs lisant cela seront sûrement d’accord).
 »

Et mon commentaire

Vous pensez sincèrement que la requête suivante (SQL Server) :

est nettement plus compliquée que celle-ci (PostGreSQL) ?

…pour reprendre votre exemple !

En sus PostGreSQL donne un résultat en anglais, même si l’installation a été faite avec une locale française, alors que SQL Server la donne dans la langue de Victor Hugo si l’utilisateur a été déclaré comme Français (avec la cédille sans les tables système…) !

4) Coût des licences

 »
Bien évidemment, tout cela sans s’acquitter de coûts de licence appliqués par serveur ou qui dépendent de la capacité et du nombre d’installations dont vous avez besoin pour déployer une architecture.
 »

Et mon commentaire :

Vous invoquez le coût inexistant des licences PostGreSQL… Vous avez bien raison. mais ça c’est la bidouille. MS SQL Server présente aussi une version gratuite, mais qui l’utilise de manière industrielle ?
Les entreprises prennent des assurances en achetant fort cher des contrats d’assistance auprès de boîtes comme 2ndQuadrant, Smile ou Dalibo en France… Qui ne font jamais du 24h/24 ni du 7j/7 !
Et ces mêmes entreprises ont souvent besoin de recourir à des prestataires PostGreSQL pour régler certains problèmes…
Alors que lorsque vous payez une licence SQL Server, vous avez droit au support 24/24 7/7…

L’entreprise SQL Spot
Le site web sur le SQL et les SGBDR

Voici le modèle de la base :

Et quelques données de test :

Nous voyons que le code SIREN de Microsoft ne se recoupe pas sur les deux tables… Cepandant nous voulons toutes les données des deux tables avec jointure sur le code SIREN ou à défaut sur le nom.
La requête suivante correspond à cette demande :

Voici ce qu’elle donne sous MS SQL Server :

CLI_ID      CLI_SIREN CLI_ENSEIGNE     PSP_ID      PSP_SIREN PSP_ENSEIGNE
----------- --------- ---------------- ----------- --------- ----------------
1           123456789 IBM              101         123456789 IBM
2           111111111 Microsoft        102         555555555 Microsoft
3           999555111 SAP              NULL        NULL      NULL
NULL        NULL      NULL             103         777777777 Amazon
NULL        NULL      NULL             104         444444444 Google

Hélas, cette requête ne passe pas sous aucune version de PostGreSQL. le message est le suivant :

ERREUR:  FULL JOIN est supporté seulement avec les conditions de jointures MERGE et de
jointures HASH JOIN
********** Erreur **********
État SQL :0A000

L’explication est la suivante :
PostGreSQL veut impérativement que la jointure soir « sargeable », c’est à dire utiliser une technique de jointure avec algorithme MERGE (fusion d’un tri resultant d’index) ou algorithme HASH (donc index avec clef de hachage)… Or, avec un « ou » (OR) dans la clause On de la jointure il n’y a pas de « sargeabilité » possible !
Si vous ne prenez pas en compte la dernière ligne (OR OR C.CLI_ENSEIGNE = P.PSP_ENSEIGNE) alors la requête s’exécute. Si vous mettez AND à la place de OR, ça passe. mais tout ceci ne donne pas le même résultat
En fait, c’est une limitation assez curieuse de l’optimiseur de PostGreSQL qui interdit le FULL OUTER JOIN dans certains cas…

Évidemment, cela constitue à l’évidence un bug…

PS : version PG testée 9.1.2 et 9.3.4

L’entreprise SQL Spot
Le site web sur le SQL et les SGBDR

Le hachage consiste à calculer une donnée de petite dimension à partir d’une donnée de grande dimension afin de s’en servir comme repère dans différents processus algorithmique. La valeur obtenu par hachage est un nombre ou une chaine binaire et dans ce dernier cas généralement représentée en hexadécimal.
Les algorithmes de hachage les plus connus sont : MD2, MD4, MD5 (16 octets / 128 bits en sortie), SHA (ou SHA-0), SHA-1 (20 octets / 160 bits en sortie), SHA-2 (224 à 512 bits), Whirlpoll (64 octets / 512 bits).
On trouvera la description des algorithmes de calcul de ces fonctions de hachage aux URL suivantes :

La valeur en sortie est de taille fixe quel que soit la longueur de l’information d’entrée. Du point de vue des mathématiques il ne peut s’agir d’un processus de cryptage puisque le cryptage produit des données dont le volume est au moins aussi important que le volume des données en entrée, voir beaucoup plus lorsque les données d’entrée sont de petits volumes.
Certains logiciels utilisent leurs propres algorithmes pour générer des valeurs de hachage. Par exemple SQL Server implémente les fonctions CHECKSUM, BINARY_CHECKSUM et CHECKSUM_AGG pour calculer un entier 32 bits à partir d’une valeur, d’une expression ou d’une liste d’expression ou de valeurs combinées, soit pour une ligne, soit pour une colonne.
On trouvera un exemple de l’algorithme utilisé à l’URL suivante : http://www.sqlteam.com/forums/topic.asp?TOPIC_ID=70832

Le hachage entraîne fatalement des collisions, c’est à dire que différentes informations peuvent produire une même valeur de hachage.

Voici un exemple de collision de hachage avec la fonction MD5…
Pour PostGreSQL :

Pour MS SQL Server :

le 20e octet est différent dans les deux chaines hexadécimales passées en argument.

Le hachage n’est pas non plus réversible. Il n’existe pas de fonction permettant à coup sûr de retrouver l’information initiale partant de la valeur hachée. La possibilité de collisions s’oppose à la bijection impérativement nécessaire à déterminer une fonction réciproque.

Le but du hachage n’est donc pas de crypter des données mais de donner une « empreinte » à une donnée.

Qu’est-ce que le cryptage ?

Le cryptage est l’ensemble des processus permettant à une donnée d’être transformée en une autre incompréhensible pour qui ne connais pas la donnée originale, puis, partant de la transformation, d’être retransformée en donnée d’origine.
Le cryptage nécessite donc l’existence de deux traitements conjoints et bijectifs : l’un de cryptage, l’autre de décryptage. On parle alors de correspondance univoque entre l’ensemble des données en clair et l’ensemble des données cryptées.
Le chiffrement est un sous ensemble du cryptage qui consiste à utiliser des fonctions mathématiques afin de crypter et de décrypter. Néanmoins il en existe d’autres comme par exemple la stéganographie…

Les techniques modernes de cryptage en matière informatique sont basées sur le chiffrement à l’aide d’algorithmes à clefs :

L’algorithme est connu et la clef de décryptage est confidentielle. La sécurité est basée sur la complexité d’un possible déchiffrement par une attaque de type « force brute » (essais de décryptage par toutes une série de clef probables).
La complexité du chiffrement est liée à l’algorithme et à la longueur de la clef. Les algorithmes à clef asymétriques étant plus fiables car plus complexes, mais aussi plus couteux en temps de traitement.

Principaux algorithmes (et longueur de clef) :

NOTA : les algorithmes de type RC sont aujourd’hui considérés comme peu fiables et ne doivent plus être utilisés en production, car ils sont faciles à casser. RC2 fût longtemps utilisé par Lotus Notes. RC4 est encore utilisé pour protéger les informations d’un réseau wifi avec clef WEP ou WPA.

Emploi du hachage

Les tous premiers emplois du hachage ont été une pseudo cryptographie à sens unique destinée à vérifier la justesse d’une information connue. Le principe est assez simple : on calcule une valeur de hachage sur des informations confidentielle et on stocke cette valeur plutôt que les informations.
Si quelqu’un vient avec les données originales que l’on hache avec le même algorithme, alors les deux valeurs (le hachage calculé et le hachage stocké) sont identiques; On suppose alors que les données sont les mêmes, ce qui, du fait des collisions potentielles est paradoxalement faux.
Mais avant l’an 2000, exploiter un véritable mécanisme de cryptage était considéré comme un crime et passible d’une peine de prison. C’est pourquoi le hachage prit de l’ampleur avant que deux choses ne se produisent :

Dès lors les algorithmes de cryptage ont remplacé la plupart des processus de hachage sauf dans les systèmes encore en vigueur dont ils constituent une part essentiel du fonctionnement.

Néanmoins le hachage peut rendre d’inestimables services. Il est notablement utilisé dans les systèmes informatiques distribués ou dans la gestion du parallélisme d’accès à des ressources d’un système, notamment pour situer une information.
Ainsi dans un système de bases de données distribuées on calculera une clef de hachage sur les éléments d’authentification de l’utilisateur et sur cette clef on calculera un modulo en fonction du nombre de nœuds dans le maillage du système distribué.
Par exemple pour un site web comme fnac.com il existe de nombreux serveurs de bases de données, chacun ayant en table tous les produits à vendre, mais un client n’existant que sur un seul des serveurs.
Tant que l’utilisateur navigue anonymement on route ses requêtes sur le serveur le moins chargé à l’instant t;
Dès qu’il est authentifié ou calcule une clef de hachage sur son mail + mot de passe, puis on calcule un modulo en fonction du nombre de serveurs et on route dorénavant toutes ses requêtes sur le serveur dont l’indice correspond au modulo, puisque c’est seulement sur ce serveur que le client est connu.

Le même algorithme est appliqué dans certains moteurs de bases de données relationnelles pour gérer des traitements en parallèle ou diminuer le temps de traitement. Par exemple pour résoudre une jointure (hash join) ou un groupage (hash group)

Emploi de la cryptographie

La cryptographie sert à rendre confidentielles certaines informations qui ne pourrons être décryptées que par ceux qui connaisse la façon de crypter et donc de décrypter.
Elle permet aussi l’authentification, par le biais de certificat qui sont des documents liant une identité à une clef par le biais d’une signature (tiers de confiance) et permettent d’avoir la certitude sur l’origine d’une entité.

Signature de documents et authentification

La signature numérique (ou signature électronique) permet de garantir l’intégrité d’un document électronique et par là même d’en authentifier l’auteur.
Elle fonctionne à l’aide d’une clef asymétrique ou d’un certificat, et une fonction de hachage :

Il est par exemple possible de « signer » un programme informatique (exécutable ou DLL).

Chiffrement de données

Un exemple typique de chiffrement est la communication d’information confidentielle par email. En effet, les données d’un email peuvent être interceptées sur le réseau Internet, ce à quoi s’emploient certaines organisations telles que la NSA.

La confidentialité des données stockées notamment dans les bases de données nécessite parfois du chiffrement. C’est le cas des données des cartes bancaires ou des données personnelles notamment dans certains domaines sensibles comme la politique, le syndicalisme, la religion ou la santé.
Dans ce dernier secteur, la Loi française impose des standards de chiffrement très élevées lorsque ces données sont accessibles sur Internet (Décret n° 2006-6 relatif à l’hébergement de données de santé à caractère personnel).

Certains SGBDR incorporent des services de génération et de gestion de clefs, de cryptage/décryptage et d’authentification par certificat. C’est par exemple le cas d’Oracle ou de MS SQL Server qui sont leurs propres autorités de certifications et stockent les clefs dans les bases.
D’autres SGBDR propose des fonctions de cryptage/décryptage sans la gestion des clefs, ce qui pose le problème de la conservation des clefs… C’est le cas de MySQL et de PostGreSQL qui nécessite un tiers externe de certification et obligent à véhiculer les clefs d’une manière ou d’une autre, souvent par le biais de fichiers sur le serveur…
Le chiffrement des données dans les bases de données posent d’ailleurs d’autres problèmes :

Le salage est abordé au paragraphe suivant et constitue une faille de sécurité importante en son absence.

La rapidité d’accès à l’information est notablement diminuée par le fait de crypter et décrypter en permanence

La volumétrie des données cryptées est plus importante en général que lorsque les données ne sont pas cryptées

Enfin, il est très difficile de rendre les recherches performantes dès lors que les données sont cryptées et salées par le simple fait qu’il est impossible d’utiliser un index et que par conséquent, il faut lire séquentiellement toutes les données et les décrypter avant d’effectuer la comparaison.

Il faut aussi faire très attention dans les bases de données au recoupement des données qui permettrait, même avec un chiffrage, de trouver certaines données. En effet, toutes les informations ne sont pas chiffrées et heureusement sinon les performances seraient catastrophiques et la base inexploitable… Mais imaginons une base de données dans laquelle nous savons qu’un des patients est un général argentin… Si ces informations figurent en clair et que, comme il est probable, il y a peu d’argentins et peu de généraux dans les données, alors il est facile de trouver ou figure cet individu dans la base et par là même de retrouver de fil en aiguille certaines informations comme son prochain rendez-vous de chimio !

Pour pallier à ce dernier inconvénient, une autre solution de chiffrement dans les bases données est basée sur le cryptage du stockage et non plus des données (TDE ou Transparent Data Encryption que l’on trouve notamment chez Oracle et MS SQL Server). Les données sont alors manipulées en clair en mémoire et de façon optimisé (utilisation des index) alors qu’elles figurent de manière chiffrées dans les fichiers (données des tables en index et journal de transactions), le cryptage/décryptage étant assurée à la volée lors des entrées / sorties au niveau du disque.

Enfin, certains SGBDR (Oracle, MS SQL Server) permmettent d’utiliser des boitiers externes de chiffrement inviolables (HSM ou Hardware Security Module) que l’on place sur le réseau et qui sont utilisés par le serveur SQL. En cas de tentative d’accès au boitier, les clefs sont automatiquement détruites.
Un exemple d’utilisation d’un HMS en pratique est celui qui protège les données personnelles confidentielles de santé des agents territoriaux de France (environ 2 millions d’individus) par le biais d’un HSM et d’un serveur de bases de données Microsoft SQL Server,

Salage

Le salage, est une méthode permettant de renforcer la sécurité des informations cryptées en y ajoutant une donnée supplémentaire afin d’empêcher que deux informations identiques conduisent aux mêmes données chiffrées. Le but du salage est de lutter contre une attaque par analyse fréquentielle.
Le cas est classique dans les bases de données. En effet, lorsque le système concentre beaucoup de données, il est fréquent de trouver des informations identiques (redondances) comme c’est par exemple le cas des noms de famille (MARTIN, DURAND, LEFEBVRE…)
Dès lors une analyse basées sur la fréquence d’apparition des redondances permettrait assez rapidement de casser le code.
Pour pallier à cet inconvénient, certains SGBDR comme Oracle ou SQL Server intègrent automatiquement un salage pour que deux données identiques donnent deux codes chiffrés différents.

NOTA : les serveurs de bases de données comme MySQL ou PostGreSQL ne permettent pas d’utiliser un salage automatique des données lors de l’utilisation des fonctions de cryptage.

Bases de données et chiffrement

À la lecture des paragraphes précédent, il apparait clair que les solutions de chiffrement actuelles dans les bases de données « libres » comme PostGreSQL ou MySQL sont incapable de procurer une sécurité suffisante :

Exemple de chiffrement de données dans les bases de données

Avec PostGreSQL, extension pgcrypto avec algorithme AES :

Cryptage :

Décryptage :

Comme on le voit, le mot de passe de la clef de cryptage est passée en clair lors de l’utilisation des fonctions de cryptage et décryptage.
Le chiffrement de MARTIN a donné deux fois le même code, la longueur du code est d’une quinzaine d’octets…

Avec SQL Server (chiffrement intégré dans toutes les versions) algorithme AES :

Cryptage :

Décryptage :

Le mot de passe de la clef n’est pas passé pour crypter et décrypter. L’ouverture de la clef peut être automatisée côté serveur par un déclencheur FOR LOGON.
Le chiffrement de MARTIN a donné deux codes différents et la longueur du code est de 52 octets…
On peut aussi utiliser un certificat à la place du mot de passe.

L’entreprise SQL Spot
Le site web sur le SQL et les SGBDR

Tout d’abord, voici les données de nos exemples…

D’abord la table :

Ensuite son alimentation, d’abord avec plus de 40 000 lignes de personnes ayant des dates de naissances continues du 1/1/1900 à nos jours…

Enfin, on y ajoutant des doublons pour la charge afin d'effectuer des tests de performances :

Ce qui remplit notre table avec plus d'un million de lignes.

Le calcul de l’âge révolu

Il fut calculer l’âge en tenant compte du jour près par rapport à la date courante.
Voici quelques approches malheureuses (fonctions SQL Server) :

Voici maintenant une formulation qui donne les réponses exactes :

Requête 1 :

Les métriques de performances relevées (4 UC), sont les suivantes :
— 1) Temps UC = 748 ms, temps écoulé = 8031 ms.
— 2) Temps UC = 515 ms, temps écoulé = 7994 ms.
— 3) Temps UC = 717 ms, temps écoulé = 7948 ms.
— 4) Temps UC = 624 ms, temps écoulé = 7932 ms.

La recherche des anniversaires

Voici tout d’abord quelques requêtes simples pour des cas triviaux :

Nous allons maintenant rechercher les personnes qui ont leur date d’anniversaire entre deux dates…

Voici tout d’abord quelques cas triviaux :

Et maintenant la solution générique :

Requête 2

Les métriques de performances relevées (4 UC), sont les suivantes :
–> 1) Temps UC = 951 ms, temps écoulé = 677 ms.
–> 2) Temps UC = 967 ms, temps écoulé = 641 ms.
–> 3) Temps UC = 890 ms, temps écoulé = 638 ms.
–> 4) Temps UC = 905 ms, temps écoulé = 663 ms.

La question est maintenant… Y a t-il des formulations plus performantes ?

L’entreprise SQL Spot
Le site web sur le SQL et les SGBDR

1 – LE PROBLÈME

Voici notre jeu de test :

Tout d’abord la table

Et ses données :

Premier essai :

Une simple requête telle que celle-ci :

Donne un résultat insatisfaisant :

Au niveau 1, « SEA » est avant « EARTH » qui lui même est avant « AIR ». Dans les deux roues (« TWO WHEELS »), « MOTORCYCLE » précède « BICYCLE ». Enfin, « CAR », « TWO WHEELS » et « TRUCK » sont mélangés.
Il n’est pas possible d’obtenir un meilleur ordonnancement directement basé sur les valeurs des colonnes actuelles de la table.

Mais la technique de l’arbre intervallaire permet d’ordonner les frères entre eux. Il suffit donc de bouger les bornes droites et gauches pour que cela corresponde à l’ordre demandé.

2 – PREMIÈRE SOLUTION

Elle consiste donc à réordonner les bornes gauche et droite.

La nouvelle table pour ce faire :

Les données réarrangées :

La requête :

Le résultat :

Critique de la première solution

La requête finale est simple. En revanche le coût est reporté lors des mises à jours (généralement peu nombreuses dans les arborescences) mais cela oblige souvent à réordonner tout l’arbre (ce qui peut se minimiser en modélisant l’arbre intervallaire à côté de la table contenant les données).
De plus, elle n’est pas satisfaisante si d’autres colonnes complique la structure de la table et qu’il faut en tenir compte dans la solution (par exemple de multiples arborescences).

3 – UNE SOLUTION GÉNÉRIQUE

Il existe une façon de faire globale, mais elle nécessite hélas une requête récursive en sus d’être gourmande en données. Cette solution consiste à rajouter un « chemin » composé d’une mixité de données comprenant les ancêtres alternés avec la position ordinale des frères entre eux. Pour la faire fonctionner correctement il est nécessaire d’utiliser une fonction de remplissage que j’ai intitulé PADMASK :

NOTA : la fonction F_PADMASK a été écrite pour MS SQL Server, et peut aisément être traduite en PGPL/SQL pour PostGreSQL.

Voici maintenant la requête :

Comme indiqué, la colonne surnuméraire de tri, PATH_MIXTE, va contenir le chemin jusqu’au nœud en cours avec entre chaque nom d’élément sa position relative dans la fratrie. Le nécessité d’utiliser la fonction de remplissage est lié au fait que notre colonne de tri contient une alternance de données numérique et alphabétique qu’il faut ordonner ensemble. or les nombres sont alignés à droite et les mots à gauche. la fonction F_PADMASK permet de coordonner ces alignements. On comprend mieux la chose en voyant ce quelle contient :

NOTA : le nombre de caractères de remplissage pour la partie alphabétique (ici colonne VHC_NOM) dépend de la longueur de la colonne (ici 16) définit à la construction de la table.

ATTENTION : Certaines formulations, comme celle données ici sur Internet « Ordering recursive result set in SQL Server » sont fausses. Je vous laisse deviner pourquoi !

Le site web sur le SQL et les SGBDR

Frédéric Brouard, alias SQLpro, ARCHITECTE DE DONNÉES

Expert  S.G.B.D  relationnelles   et   langage  S.Q.L

Moste  Valuable  Professionnal  Microsoft  SQL Server

Société SQLspot  :  modélisation, conseil, formation,

optimisation,  audit,  tuning,  administration  SGBDR

Enseignant: CNAM PACA, ISEN Toulon, CESI Aix en Prov.

L’ntreprise SQL Spot

Les données que l’on y insère sont les suivantes :

Que l’on peut présenter ainsi :

Le calcul du niveau peut se faire par la requête :

En fait il s’agit de compter le nombre de parents d’un nœud.

Pour rajouter le calcul du niveau en dur dans la table, on peut faire comme ceci :

Ce qui rajoute la colonne niveau dans la table.

Il faut maintenant la mettre à jour :

Le site web sur le SQL et les SGBDR

Frédéric Brouard, alias SQLpro, ARCHITECTE DE DONNÉES

Expert  S.G.B.D  relationnelles   et   langage  S.Q.L

Moste  Valuable  Professionnal  Microsoft  SQL Server

Société SQLspot  :  modélisation, conseil, formation,

optimisation,  audit,  tuning,  administration  SGBDR

Enseignant: CNAM PACA, ISEN Toulon, CESI Aix en Prov.

L’ntreprise SQL Spot

Le site web sur le SQL et les SGBDR

Frédéric Brouard, alias SQLpro, ARCHITECTE DE DONNÉES

Expert  S.G.B.D  relationnelles   et   langage  S.Q.L

Moste  Valuable  Professionnal  Microsoft  SQL Server

Société SQLspot  :  modélisation, conseil, formation,

optimisation,  audit,  tuning,  administration  SGBDR

Enseignant: CNAM PACA, ISEN Toulon, CESI Aix en Prov.

L’ntreprise SQL Spot

Le site web sur le SQL et les SGBDR

Frédéric Brouard, alias SQLpro, ARCHITECTE DE DONNÉES

Expert  S.G.B.D  relationnelles   et   langage  S.Q.L

Moste  Valuable  Professionnal  Microsoft  SQL Server

Société SQLspot  :  modélisation, conseil, formation,

optimisation,  audit,  tuning,  administration  SGBDR

Enseignant: CNAM PACA, ISEN Toulon, CESI Aix en Prov.

L’ntreprise SQL Spot