Le blog de SQLpro » bases de données

Modèle générique vs modèle spécifique

SQLpro — Fri, 10 Aug 2018 08:04:43 +0000

Dans le cadre d’un héritage de données ayant de multiples enfants aux caractéristiques très diverses, est-il préférable de concevoir un modèle de données générique ou un modèle de données spécifique ? De nombreux jeunes développeurs pensent naïvement qu’un modèle générique est plus facile… Mais c’est souvent une erreur qu’il faudra payer au prix fort une fois l’application fonctionnelle. Démonstration…

Je suis partit initialement de ce post :

Avis sur l’architecture de ma base de données (choix de l’option)

La demande étant la suivante :

J’ai 30 familles de critères. Chaque famille comporte un nombre variable de critères pour un total d’environ 600 critères.
Chaque critère appartient à une seule famille de sorte que les 600 sont à répartir dans les 30 familles.
Ma question:
– devrais-je créer une table par famille et insérer dans chaque table les critères qui lui appartiennent; (solution 1)
ou alors:
– créer une table contenant les 30 familles et une autre contenant les 600 critères. Ensuite, créer les relations qui lient chaque famille à ses critères et/ou inversement. (solution 2)

et ma réponse :

Pour qu’une base réponde bien en terme de performances, on doit tout faire pour minimiser les IO.
– Dans votre solution 1, les performances seront bonne si la plupart des requêtes portent sur plusieurs critères d’une même famille
– Dans votre solution 2, les performances seront bonne si la plupart des requêtes portent sur un seul critère.

Cependant un jeune internaute peu avisé, affirmait avec force que :

pour moi la solution 2 est la + simple à mettre en place.
et le nombre d’enregistrements ne justifie pas la solution 1..
tout dépend de votre SGBD (pas précisé..), mais dans tous les cas, il suffit de mettre des ID numérique pour que les requêtes soient optimisées. Créez vos tables avec des id uniques (sous Oracle on peux utiliser les séquences) et vous aurez des traitements optimisées au mieux… mais bon, je vous rassure, sous Oracle, même avec des clefs en Varchar, pour 600 enregistrements, y a aucun pb..
si je vois bien, vous aurez donc 3 tables avec les clef suivante :
– FAMILLE (Pk : ID_FAMILLE)
– FAMILLE_CRITERE (Pk : ID_FAMILLE, ID_CRITERE)
– CRITERE (Pk : ID_CRITERE)
Relations :
¤ Famille –> FAMILLE_CRITERES <— CRITERE
famille_critere ne contenant que le couple ID_FAMILLE, ID_CRITERE (on parle de table intermédiaire)

Ce à quoi je répondais :

La solution 2 est correcte si vous ne requêtez JAMAIS plus d’un critère à la fois. Elle est déjà moins performante à l’insertion/la mise à jour des données…
La solution 2 est imbécile, complexe et peu performantes si vous avez plusieurs critères a rechercher…
En sus, elle ne permet pas facilement de typer les informations, donc, vous aurez beaucoup de problématique de contrôle de qualité… et des performances catastrophiques

DÉMONSTRATION

Partons d’une table d’animaux :

CREATE TABLE T_ANIMAL_ANM
(ANM_ID INT PRIMARY KEY,
ANM_DATA CHAR(8000) NOT NULL);
GO

INSERT INTO T_ANIMAL_ANM VALUES (1, 'Mytilus Edulis')

█ █ █ 1ere solution : une seule table pour toute une même famille :

CREATE TABLE T_MOLUSQUE_MSQ
(ANM_ID INT PRIMARY KEY REFERENCES T_ANIMAL_ANM (ANM_ID),
MSQ_CARAPACE VARCHAR(32),
MSQ_SYMETRIE VARCHAR(32),
MSQ_COULEUR VARCHAR(32),
MSQ_DIAMETRE_MM FLOAT);

█ █ █ 2e solution (pour toutes familles), des tables « génériques » :

CREATE TABLE T_CARATERISTIQUE_CRT
(CRT_ID INT PRIMARY KEY,
CRT_LIBELLE VARCHAR(256));

CREATE TABLE T_VALEUR_VLR
(ANM_ID INT NOT NULL REFERENCES T_ANIMAL_ANM (ANM_ID),
CRT_ID INT NOT NULL REFERENCES T_CARATERISTIQUE_CRT(CRT_ID),
VLR_VALEUR VARCHAR(256),
PRIMARY KEY (ANM_ID, CRT_ID));

Ajoutons les caractéristiques identiques à celle de la solution 1

INSERT INTO T_CARATERISTIQUE_CRT VALUES (111, 'Carapace');
INSERT INTO T_CARATERISTIQUE_CRT VALUES (222, 'Symétrie');
INSERT INTO T_CARATERISTIQUE_CRT VALUES (333, 'Couleur');
INSERT INTO T_CARATERISTIQUE_CRT VALUES (444, 'Diamètre mm');

█ █ █ Voici maintenant les insertions :

Pour la solution 1 :

INSERT INTO T_MOLUSQUE_MSQ (ANM_ID, MSQ_CARAPACE, MSQ_SYMETRIE, MSQ_COULEUR, MSQ_DIAMETRE_MM)
VALUES (1, 'Creatine', 'Mono', 'Bleu', '82.5')

Notez que nous n’avons fait qu’une seule requête d’insertion avec correspondance caractéristique / valeur et typage des données

Pour la solution 2 :

INSERT INTO T_VALEUR_VLR
SELECT 1, CRT_ID, 'Creatine' FROM T_CARATERISTIQUE_CRT
WHERE CRT_LIBELLE = 'Carapace';

INSERT INTO T_VALEUR_VLR
SELECT 1, CRT_ID, 'Mono' FROM T_CARATERISTIQUE_CRT
WHERE CRT_LIBELLE = 'Symétrie';

INSERT INTO T_VALEUR_VLR
SELECT 1, CRT_ID, 'Bleu' FROM T_CARATERISTIQUE_CRT
WHERE CRT_LIBELLE = 'Couleur';

INSERT INTO T_VALEUR_VLR
SELECT 1, CRT_ID, '82,5' FROM T_CARATERISTIQUE_CRT
WHERE CRT_LIBELLE = 'Diamètre mm';

Pour stocker les mêmes informations, nous avons fait 4 requêtes au lieu d’une seule….

█ Comparons maintenant le coût des 2 solutions au niveau de l’insertion :

Y’a pas à tortiller 4 requêtes coutant deux fois plus cher qu’une seule et unique requête cela est donc 8 fois plus couteux…

█ █ █ Voyons maintenant la facilité de requêtage :

interrogation multicritères ET avec solution 1

SELECT *
FROM T_ANIMAL_ANM AS A
JOIN T_MOLUSQUE_MSQ AS M
ON A.ANM_ID = M.ANM_ID
WHERE MSQ_CARAPACE = 'Creatine'
AND MSQ_SYMETRIE IN ('Mono', 'Double')
AND MSQ_COULEUR LIKE 'Bleu%' --> peut être Bleue, Bleu-marine...
AND MSQ_DIAMETRE_MM BETWEEN 75 AND 92;

la requête fait 8 lignes et 1 jointure. Elle en fera une de plus pour chaque critère supplémentaire avec juste quelques chose à rajouter à la clause WHERE…

interrogation multicritères ET avec solution 2

SELECT *
FROM T_ANIMAL_ANM AS A
JOIN T_VALEUR_VLR AS V1
ON A.ANM_ID = V1.ANM_ID
JOIN T_CARATERISTIQUE_CRT AS C1
ON V1.CRT_ID = C1.CRT_ID
JOIN T_VALEUR_VLR AS V2
ON A.ANM_ID = V2.ANM_ID
JOIN T_CARATERISTIQUE_CRT AS C2
ON V2.CRT_ID = C2.CRT_ID
JOIN T_VALEUR_VLR AS V3
ON A.ANM_ID = V3.ANM_ID
JOIN T_CARATERISTIQUE_CRT AS C3
ON V3.CRT_ID = C3.CRT_ID
JOIN T_VALEUR_VLR AS V4
ON A.ANM_ID = V4.ANM_ID
JOIN T_CARATERISTIQUE_CRT AS C4
ON V4.CRT_ID = C4.CRT_ID
WHERE C1.CRT_LIBELLE = 'Carapace'
AND V1.VLR_VALEUR = 'Creatine'
AND C2.CRT_LIBELLE = 'Symétrie'
AND V2.VLR_VALEUR IN ('Mono', 'Double')
AND C3.CRT_LIBELLE = 'Couleur'
AND V3.VLR_VALEUR LIKE 'Bleu%'
AND C4.CRT_LIBELLE = 'Diamètre mm'
AND V4.VLR_VALEUR BETWEEN '75' AND '92'

La requête fait 26 lignes avec 8 jointures… Il faudra rajouter 6 lignes à chaque critère supplémentaire, dont 4 dans la clause FROM et 2 dans le WHERE, et encore, on ne sait pas dans la clause SELECT à quelle caractéristique se réfère chacune des valeurs… Il faudrait aussi customiser la clause SELECT…

Y’a pas à tortiller la solution 1 est bien plus simple en matière d’écriture…

█ Quelles sont les performances des requêtes de recherches des deux solutions ?

Évidemment la première solution est 4,5 fois moins couteuse…

Mais il y a pire… J’ai du mettre des chiffres en chaine de caractères pour le diamètre (AND V4.VLR_VALEUR BETWEEN ’75’ AND ’92’). Si je tente de les typer en entier ou réel (AND V4.VLR_VALEUR BETWEEN 75 AND 92), cela provoque une erreur d’exécution (SQL Server) :
Msg*245, Niveau*16, État*1, Ligne*75
Échec de la conversion de la valeur varchar ‘Creatine’ en type de données int.
Logique car pour effectuer une comparaison avec une valeur numérique, il faut convertir la colonne en numérique, mais comme il y a autres chose que de purs nombres (chaines de caractères) cela se passe mal.
Bref certaines requêtes seront impossible à faire !

Plus catastrophique encore… mettre des index ne servira quasiment à rien ! En effet un index sur une chaine de caractères n’ordonne pas les valeurs de la même façon que s’il s’agissait de nombre…

En sus rien n’interdira à quelqu’un de saisir 8,2 au lieu de 8.2 (une virgule au lieu d’une point) comme diamètre, dans ce modèle inepte, alors qu’avec le bon modèle les types sont respectés…. Si tel était le cas, la valeur ne pourra pas être retrouvée !!! Il existe bien évidemment une solution pour contourner, un tout petit peu, ce modèle pourri, pour le typage. Il consiste à rajouter autant de tables de valeurs que de type… Mais il n’est pas possible de rajouter des contraintes spécifique à chaque type (par exemple vérifier qu’une pourcentage est bien entre 0 et 100 – notion de domaine SQL), ni, bien entendu, de rajouter des contraintes multicritères (une valeur dépendant d’une autre) comme c’est le cas par exemple de la chronologie des temporels de type « début » et « fin ».
Et dans tous les cas, les requêtes seront encore plus complexes à élaborer et les performances encore plus lamentables…

En guise de conclusion

Nous vous avons démontré les performances lamentable et la complexité horrifiante d’un tel modèle….

Complexité d’insertion des données

Mauvaise performances à l’insertion des données

Complexité d’écriture des recherches

Mauvaise performances pour la recherches de données

Impossibilité de typer finement (notion de domaine)

Impossibilité de placer des contraintes multicritères

Difficultés pour l’indexation

Mais comment se fait-il que des internautes osent affirmer de pareilles stupidités ?

Il est amusant de voir que certains développeur incultes affirment n’importe quoi, par ignorance, ou par bêtise, ne prenant même pas la peine de tester ce qu’ils disent… Ensuite ces mêmes développeurs, sans aucune expérience, iront vous raconter que les SGBDR c’est pas performant… Ils vous vendrons alors du NoSQL, ce qui, dans beaucoup de cas, sera pire encore !

Comme disent les américains : « garbage in, garbage out » qui peut se traduire si tu fais de la merde en entrée, tu auras de la merde en sortie ! Autrement dit, si le modèle de données est inepte, la qualité des données sera pourrie et les performances lamentables…

Décortiquons d’ailleurs les affirmations de l’internate que nous avons cité :
« tout dépend de votre SGBD (pas précisé..), mais dans tous les cas, il suffit de mettre des ID numérique pour que les requêtes soient optimisées. Créez vos tables avec des id uniques (sous Oracle on peux utiliser les séquences) et vous aurez des traitements optimisées au mieux… mais bon, je vous rassure, sous Oracle, même avec des clefs en Varchar, pour 600 enregistrements, y a aucun pb.. »

Première affirmation stupide : « tout dépend de votre SGBD (pas précisé..) »
Comme nous sommes dans un forum sur les SGBDR, sachez cher monsieur, que tout les SGBDR fonctionnent de la même façon. Certains allant plus vite que d’autre (une Ferrari va généralement plus vite qu’une Peugeot), certains avec plus de qualité que d’autres (une Rolls-Royce est généralement de meilleure qualité qu’une Dacia).

Seconde affirmation stupide : « il suffit de mettre des ID numérique pour que les requêtes soient optimisées »
Si c’était le cas alors, pas besoin d’index ni de contraintes… On se demande donc pourquoi les éditeurs de SGBDR font de tels effort en R&D pour trouver de nouvelles formes d’index toujours plus performant… Et la plupart des informaticiens ignorent que les contraintes permettent de mieux optimiser les plans de requête… Hélas ceci est très rarement enseigné par les professeurs des universités et encore moins ceux des écoles d’ingénieurs… (je le sais pertinemment puisque j’en étais un…).

Troisième affirmation stupide : « mais bon, je vous rassure, sous Oracle, même avec des clefs en Varchar »
Et bien, non, plus une clef est longue en nombre d’octets, plus ses performances décroissent. Pour avoir la même longueur qu’un entier auto incrémenté il faudrait se limiter à 4 caractères… En sus certaines phénomènes apparaissent avec des clefs non numériques et en particulier pour des clefs littérales :

distribution peu aléatoire (parce que concentrées sur les 26 lettres et 10 chiffres parmi les 256 caractères disponibles) induisant des statistiques d’optimisation mal réparties (histogrammes erratiques)

extra-overhead lié à la gestion de la collation (sensibilité ou non à la casse, aux accents…)

façon de stocker physiquement les VARCHAR induisant des octets suplementaires et de la fragmentaion en cas d’UPDATE

Quatrième affirmation stupide : « sous Oracle, même avec des clefs en Varchar, pour 600 enregistrements, y a aucun pb.. »
Nous avons déjà dit précédemment que les clef littérales (VARCHAR) étaient une plaie… Mais ce qui ne va pas dans cette phrase est le terme « enregistrement« … Cet internaute sait-il au moins que les SGBDR ne travaillent pas avec des « enregistrement » propre aux bases de données de type « fichier » comme c’était las cas dans les années 50 à 70 ? Les SGBDR structurent les lignes des tables dans des pages qui sont modifiées en mémoire et non pas directement sur le disque (notion physique d’enregistrement). Les pages étant physiquement écrites de temps à autres quand il y en a suffisamment à écrire par un processus asynchrone travaillant en tâche de fond.

Bref voici q’un internaute ne connaissant ni la modélisation des données ni les technologies des SGDB, vient donner des conseils stupides hélas parfois repris dans certaines applications….

CQFD

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’entreprise SQL Spot
Le site web sur le SQL et les SGBDR

Cosmos DB, la base NoSQL à tout faire !

SQLpro — Mon, 06 Aug 2018 16:19:14 +0000

Vous en rêviez ? Cosmos DB l’a fait ! Une seul base de données, permettant à la fois et dans un même espace de stockage de combiner les différentes technologies des bases de données NoSQL… « Wide Column », « Graph Database », « Key-Value » et « Document Stores », toutes ces technologies sont disponible dans une seule et même base de données de nom Cosmos DB…

Là ou certaines clients doivent jongler avec plusieurs SGBD pour satisfaire différentes facettes fonctionnelles, Cosmos DB fait la synthèses des plus importantes technologies utilisées de manière combinées dans un seul et même produit.

Je me suis amusé à comparer, via le célèbre site db-engines.com qui publie des résultats de collecte de données statistiques d’utilisation, les différents graphes de popularité des produits concurrents de Cosmos DB et n’ai retenu que les SGBD qui lui était encore supérieur… Force est de constater la progression fulgurante de Cosmos DB qui, en quelques mois à dépassé OrientDB, Oracle Berkely DB, CouchDB, Google Cloud, MarkLogic, Google Big Table…
Et Cosmos DB talonne Cassandra, HBase, Neo4J, MongoDB, Memcached, Amazon DynamoDB et Redis.

1 – Graphe de popularité Key-value stores

Cosmos DB progresse de 29 fois en 4 ans alors que Redis (leader) n’a fais que 4,6 sur la même période !

2 – Graphe de popularité Wide Columns stores

Cosmos DB progresse de 29 fois en 4 ans alors que Cassandra (leader) n’a fais que 1,4 sur la même période !

3 – Graphe de popularité Graph DBMS

Cosmos DB progresse de 29 fois en 4 ans alors que Neo4j (leader) n’a fais que 1,7 sur la même période !

4 – Graphe de popularité Document Stores

Cosmos DB progresse de 29 fois en 4 ans alors que MongoDB (leader) n’a fais que 1,46 sur la même période !

Allez, je fais un pari… Avant 2 ans, Cosmos DB sera au pire, la seconde base en popularité dans chacune de ces 4 catégories avec comme unique « sparring partner » :

Redis pour la partie Key-Value

MongoDB pour la partie Document Stores

Neo4J pour la partie « graph database » (et là je pense que Cosmos DB va le doubler)

Cassandra pour la partie « Wide Column »

Je parie aussi pour la disparition, à plus ou moins long terme, de produits comme OrientDB, CouchDB et MarkLogic…

Donc rendez vous début août 2020…

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

Qui est leader dans les bases de données en 2016 ?

SQLpro — Thu, 27 Oct 2016 14:43:33 +0000

Selon l’étude 2016 du groupe Gartner au sujet des bases de données opérationnelles d’entreprise (OPDBMS), Microsoft est le n°1 sur les deux axes de mesure : facilité d’utilisation et visionnaire.

Source : Gartner – Magic Quadrant for Operational Database Management Systems 2016

Microsoft détient l’un des systèmes de bases de données relationnelles les mieux conçu, les plus utilisés et le plus fiable avec SQL Server, incorporant un moteur « in memory » (IMDBMS).
Mais il se trouve que Microsoft est aussi le numéro deux du cloud derrière Amazon (Azure SQL Database).
Il offre aussi différentes technologies complémentaire de type NoSQL avec Azure DocumentDB (un SGBD de type « document ») et Azure Tables (un SGBDR de type paire clef/valeur).
Très présent dans le cloud, y compris de manière hybride (une base SQL Serveur locale peut avoir une partie de ses données dans le cloud via le concept de « stretch tables« ), Microsoft offre aussi de nombreuses possibilité analytiques ou mobile.

Pour la troisième année consécutive Mictrosoft est numéro 2 en part de marché sur le plan financier, derrière Oracle dont le Gartner Group a remonté comme point négatif de l’étude, les problèmes de coûts, de complexité de licences et noté un rapport qualité prix jugé négatif par les clients.

Mais ce qui fait la force de Microsoft depuis toujours, et celle en particulier de ses solutions de bases de données, c’est la facilité d’utilisation (l’un des meilleurs scores de l’étude) et de migration de version (80% des clients ont trouvés que la migration des bases était plus facile que prévue ou autant que prévu)…

Les seuls problèmes pointés du doigt de manière négatives par le Gartner Group sont exclusivement celles liées au marketing, canaux de vente et distribution des solutions Microsoft ou l’éditeur reste encore perçut par certains comme un acteurs pour de petites solutions…
Finalement aucune critique technique ni financière ne vient ternir l’image d’excellence de Microsoft dans le domaines des bases de données d’entreprise ce qui tend à prouver que ce classement de leader est largement mérité !

***

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

Oracle vs SQL Server : les options payantes qui font la différence…

SQLpro — Fri, 26 Feb 2016 09:06:50 +0000

Le monde des utilisateurs de bases de données d’Oracle commence à se faire du soucis, car la firme ayant besoin d’argent (le cours de son action baisse inexorablement depuis de nombreux mois) elle cherche par tous les moyens à racler les fonds de tiroir auprès de ses clients. L’une de ses stratégies consiste à jouer sur les options payantes… Or il se trouve que chez SQL Server le concept d’option payantes n’existe pas… Cet article fait le point sur la pratique agressive d’Oracle et compare les tarifs appliqués à Oracle à son principal adversaire, SQL Server de Microsoft.

1 – Le problème
Dans un article de « Business Insider » , un client se plaignait qu’Oracle menaçait de lui faire payer des sommes exorbitantes sauf s’il se décidait a aller dans le cloud d’Oracle. Pour arriver à faire cracher un volume exorbitant de licences, Oracle utilise une technique particulièrement tordue qui consiste à faire payer de nombreuses options, même si elles n’ont jamais été utilisées en production…
Explication :
La base de données Oracle est dotée de nombreuses options, autrefois toutes payantes. Au fil du temps et des versions, certaines options sont devenues des fonctionnalités gratuites, sans que développeurs ni dba ne sachent vraiment lesquelles le sont et, celles qui ne le sont pas. Dans la pratique certains utilisateurs activent soit volontairement pour test, soit par inadvertance, des fonctionnalités dont quelques unes sont payantes. Malheureusement ceci est tracé et l’activation d’une telle fonctionnalité ouvre immédiatement droit au paiement supplémentaire même si on ne l’utilise pas, Oracle arguant qu’il ne lui est pas possible rétrospectivement de savoir si la fonctionnalité a été réellement utilisée, simplement testée voir même totalement inutilisée. De plus, au moment de l’activation d’une fonctionnalité payante, aucun message préventif n’indique que l’option fera l’objet d’une licence complémentaire ouvrant droit à subsides au profit d’Oracle.
Une fois le temps de l’audit venu, Oracle n’a plus qu’a interroger les traces indélébiles de l’activation de ces options et envoyer la note !

2 – Pourquoi ?
Nous avons dit que la firme Oracle a besoin d’argent… Il suffit de regarder les cours de bourse d’Oracle pour constater son inexorable déclin. Dans le même temps, comparer ceux de son principal challenger Microsoft…

Comment Oracle en est-il arrivé là ? Il n’y a pas que le prix exorbitant des licences qui font reculer les clients… D’autres éléments clefs font rétrécir la part de marché d’Oracle. Cela a commencé il y a plus de 10 ans, lorsqu’est sortit la version 2005 de SQL Server de Microsoft. À l’époque, Oracle se croyait « unbreakable ». Hélas plusieurs analystes montraient que sur le plan de la sécurité Oracle était bien moins bonne que celle de SQL Server, avec des bogues récurrents et un temps de correction anormalement lent (voir notamment l’étude de David Litchfield de 2006). Sécurité qui ne s’est pas améliorée hélas au fil du temps ou les comparaisons basées sur les failles (CVE : Common Vulnerabilities and Exposures) recensées par le NIST (National Institute of Standards and Technology) donne un avantage de plus en plus grand à SQL Server au détriment d’Oracle sur le plan des failles de sécurité ! (voire l’étude Edison de 2013)

Etude Litchfield – comparatif de sécurité entre Oracle et SQL Server de 2000 à 2006

Etude Edison – CVE NIST historique des vulnérabilités Oracle vs SQL Server

Enfin, les enquêtes de satisfaction donnent un réel avantage à SQL Server (voir les enquêtes « State on Database Technology » d’Information Week ou encore les différentes études ITC).

Bases de données les plus utilisées pour les missions critiques (source Information Week – State of Database Technologie 2016)

Quant au cout global d’utilisation, il est depuis bien longtemps en faveur de SQL Server (simplicité des commandes, facilité de l’IHM, documentation exceptionnelle…) malgré les nombreux papiers dont Oracle inonde le web afin de tenter de prouver le contraire ! Il suffit de demander à des dba ayant la double casquette ce qu’ils en pense… (voire par exemple l’étude Alinean de 2015).

Outre ces éléments il y a un facteur majeur qui rentre en ligne de compte sur le long terme. Le cloud (infonuagique) !… Larry Ellison y a longtemps été peu favorable et indécis. Le résultat est sans appel. Microsoft y existe et s’en trouve être un des leader derrière Amazon. Oracle n’existe pas sur ce marché. Les enquêtes du Gartner Group (Magic Quadrant pour le cloud) le montre bien…

Gartner Magic Quadrant 2014 for Cloud Infrastructure as a Service

Gartner Magic Quadrant 2015 for Cloud Infrastructure as a Service

2 – Des pratiques scandaleuses
Dans l’article de Business Insider une pratique s’apparente à du chantage. Oracle consent à réduire l’addition, si le client passe dans le cloud. Or nous venons de le voir, les clients sont loin de se précipiter dans l’infonuagique à la sauce Oracle, lui préférant de loin Amazon lorsqu’ils restent Oracleur ou Azure lorsqu’ils passent à SQL Server.
Un autre article (« Comment se déroule un audit logiciel avec Oracle… » du Monde Informatique) montrent à quel point les pratiques d’Oracle sont scandaleuses et frisent le hors la Loi… « Oracle réclame des informations qu’elle n’est pas supposée demander contractuellement sur les serveurs sur lesquels ne tournent pas de logiciel Oracle et sur le personnel de Mars qui n’utilise pas les logiciels d’Oracle« . Imaginez quelles sont les implications d’une telle intrusion dans vos serveurs ou auprès de vos employés !
D’où les conseils distillés par certains juriste et économistes, d’intégrer les risques de coûts associés aux audits d’Oracle comme charges supplémentaire aux offres commerciales, ce qui a pour effet de gonfler la note finale d’acquisition des licences Oracle !

3 – les options payantes
Je me suis livré à une comparaisons des options payantes dans oracle et gratuites dans SQL Server. Microsoft n’offre d’ailleurs pas d’options payantes, mais les fonctionnalités dépendant des versions (comme dans Oracle d’ailleurs). De plus, il existe de nombreux outils complémentaires gratuits pour SQL Server disponible sur le site web communautaire codeplex.
Voici un tableau résumant la chose :

Comparaison des fonctionnalités Oracle (payantes) et SQL Server (gratuites)

4 – Le prix…
De la même manière, j’ai étudié le montant comparatif des licences à payer pour l’équivalence d’Oracle avec SQL Server, basé sur la version Enterprise. Le résultat est édifiant…
Prix des options Oracle (21 juin 2016) « Processor Licence » :

Active Data Guard 11 500 $
Database In-Memory 23 000 $
Diagnostics Pack 7 500 $
Tuning Pack 5 000 $
Partitionning 11 500 $
Advanced compression 11 500 $
OLAP 23 000 $
Advanced Analytics 23 000 $
Spatial 17 500 $
Multitenant 17 500 $
TOTAL : 139 500 $

Prix des licences Oracle édition Enterprise : 47 500 $
Le prix des licences Oracle s’établie pour 2 processeurs. Par exemple sur une machine quadriprocesseur ayant des CPU comportant 12 coeurs, le facteur de licence est donc de 24 (4 x 12 / 2).

Prix des licences SQL Server édition Enterprise : 27 496 $
Le prix des licences SQL Server s’établie pour 4 processeurs. Par exemple sur une machine quadriprocesseur ayant des CPU comportant 12 coeurs, le facteur de licence est donc de 12 (4 x 12 / 4).

Comparaison basé sur le prix au processeur : (47 500 / 2) / (27 496 / 4) = 4
Oracle, sans aucune option payante, est donc naturellement 4 fois plus cher que SQL Server

Avec notre machine exemple (quadriprocesseur ayant des CPU comportant 12 coeurs) et toutes les options, nous arrivons à la différence suivante :
Oracle : 24 x ( 47 500 + 139 500 ) = 4 488 000 $
SQL Server : 12 x 27 496 = 329 952 $
À ce stade, Oracle est 13,6 fois plus cher…

Mais vous pouvez négocier !

les remises maximales chez Oracle vont jusqu’à 70%, vous passez donc à : 1 346 400 $
les remises maximales chez Microsoft vont jusqu’à 40%, vous passez donc à : 197 971 $

De plus si vous avez misé sur des serveur dotés de processeurs OPTERON d’AMD, alors Microsoft accorde un facteur de réfaction supplémentaire de 25%. La note passe donc à 148 478 $
Après négociation et utilisation de processeurs Opteron d’AMD, au final, Oracle s’avère 9 fois plus cher…

En conclusion

Comme je le mentionnait dans un article précédent « le déclin d’Oracle » la firme de Redwood Shores est en sérieuse perte de vitesse. Elle n’est même plus le champion de l’avancée technologique. Par exemple elle s’est faite grillée sur le « In Memory » par SAP avec HanaDB, puis par SQL Server…
Sur les performances la plupart des benchmarks effectués par les utilisateurs montre quelle est plus gourmande à performances équivalente que la plupart de ses challengers ou si l’on prend l’autre bout de la lorgnette, qu’elle est moins performantes sur une même machine. Mais Oracle interdisant de publier le moindre benchmark concernant le produit, vous ne trouverez pas d’étude sérieuses sur le sujet. Reste les benchmarks officiels du TPC, mais là c’est une autre histoire… Oracle ne publie que les résultats du TCP-C datant de 1992 donc sur une base de données datée de 23 ans comportant en tout et pour tout 8 tables et des jointures limitées à 2 tables sans aucune sous requête ! Et même dans ce cas, SQL AnyWhere de SAP (anciennement Syabse) la bât sur le coût…
En revanche SQL Server se sert du TPC-E plus récent (2007) et plus réaliste, comportant 33 tables des jointures avec 7 tables et de multiples sous requêtes. Et là curieusement, Oracle n’y a jamais présenté un seul résultat de benchmark !
Et ce déclin est bien constaté par d’inexorables chiffres. Par exemple celui comparant, pour un organisme de formation bien connu pour son indépendance, le nombre de stagiaires formés sur chacune des deux plateformes…

Formation professionnelle – évolution 2005-2015 Oracle vs SQL Server

Pas la peine de vous faire un dessin !

Un point sur les collations…

SQLpro — Mon, 19 Jan 2015 10:13:20 +0000

Voici une réponse de forum dans laquelle je précise comment sont gérées les collations dans les SGBDR.

http://www.developpez.net/forums/d1397211/bases-donnees/langage-sql/utilisation-d-between-chaine-caracteres/#post7632749

À noter : Oracle ne dispose pas de collation mais de l’imbitable NLS qui ne permet pas entre autre :
– de gérer différentes collations au sein d’une même requête (par exemple faire une recherche de login en ne tenant pas compte de la casse et du mot de passe associé en tenant compte de la casse et des diacritiques.
– de faire des recherches sans tenir compte de la casse, mais en tenant compte des accents, pas exemple pour différencier « maïs » de « mais » lorsque l’on travaille chez un semencier !

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

Données géographiques gratuites pour la France

SQLpro — Tue, 23 Sep 2014 11:50:40 +0000

Voici un ensemble d’URL pour télécharger des données cartographiques et géographiques françaises…

Collectivités locales – voies et lieux-dits en France :

http://www.collectivites-locales.gouv.fr/mise-a-disposition-fichier-fantoir-des-voies-et-lieux-dits

INSEE – découpages géographiques nationaux officiels (COG) :
– communes
– cantons
– arrondissements
– départements
– régions

Documentation : http://www.insee.fr/fr/methodes/nomenclatures/cog/documentation.asp
Téléchargement : http://www.insee.fr/fr/methodes/nomenclatures/cog/telechargement.asp

IGN – Bases géomatiques diverses :

http://professionnels.ign.fr/gratuit

Le déclin d’Oracle ?

SQLpro — Tue, 24 Jun 2014 10:20:14 +0000

De récentes études montre l’inexorable déclin d’Oracle…

Dans une étude récente* sur l’utilisation des bases de données SQL et NoSQL, menée par l’entreprise Tesora, on note, sur la question de quels SGBDR sont actuellement utilisés en entreprise, les chiffres suivants :
– Microsoft SQL Server : 57 %
– MySQL : 40 %
– Oracle : 38 %
– IBM DB2 : 14 %
– PostgreSQL : 13 %
NOTA : le total est supérieur à 100%, les entreprises ayant souvent plusieurs SGBDR.

Une autre étude*** datant de mars 2014, menée par Information Week, intitulée « 2014 State of
Database Technology », montre les métriques suivantes :
Bases de données utilisées pour les missions les plus critiques (voir figure ci après) – 3 réponses possibles :
– Microsoft SQL Server : 57 %
– Oracle : 38 %
– MySQL : 13 %
– IBM DB2 : 11 %
– Microsoft Access : 11 %
– PostgreSQL : 3 %
…

Oracle surpassé par SQL Server dans les fonctions d’entreprise les plus critiques

Bases de données en usage dans l’entreprise :
– Microsoft SQL Server : 75 %
– Microsoft Access : 48 %
– Oracle : 47 %
– MySQL : 37%
– IBM DB2 : 17 %
– PostgreSQL : 10 %
…

Il y a quelques années, Oracle était en tête dans des études similaires. Aujourd’hui Oracle est passé derrière SQL Server depuis quelques années, et même derrière MySQL détenu aussi par Oracle et parfois même derrière Microsoft Access !

Un déclin confirmé en France d’une part, par le nombre important de consultants ayants des difficultés à trouver des contrats, et d’autre part, par des tarifs journaliers en baisse.
Ainsi, au début des années 2000, un spécialiste Oracle décrochait facilement des journées de prestation pour des missions courtes avec un tarif généralement très supérieur au millier d’euros.
Aujourd’hui le prix de journée a été presque divisé par deux tant l’offre est importante et la demande est faible…

Autre élément contribuant au déclin d’Oracle : un prix de licence élevé, une forte complexité d’administration et une sécurité très en dessous de celle de SQL Server.
On constate dans les faits de nombreuses migrations de bases Oracle vers PostGreSQL, MySQL ou SQL Server. Plusieurs outils d’aide à la migration (assistants) ont vu le jour récemment.

* : étude Tesora « Database Usage in the Public and Private Cloud: Choices and Preferences, » menée auprès de 500 « répondants » du « North American developer communities » dans des entreprise qui se définissent elles-même comme adepte, dès les premiers temps, des nouvelles technologies et ayant adopté l’open source.
** : étude Information Week, intitulée « 2014 State of Database Technology » de mars 2014, auprès de 956 répondants destinée à déterminer le rôle des technologies de bases de données dans l’entreprise.

Autres études :

Embarcadero Technologies’ Database Survey Report (décembre 2010)

SQL Server Most Secure Database – Oracle Least Secure Database Since 2002 (septembre 2010)

Microsoft SQL Server 2012 Vs. Oracle: Customers Voting (septembre 2012)

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

Hachage n’est pas cryptage ! De la sécurité des données chiffrées dans les SGBDR

SQLpro — Wed, 19 Feb 2014 10:24:54 +0000

De plus en plus de jeunes développeurs confondent la technique du hachage et le chiffrement des données. Voici un point sur le sujet…

Qu’est-ce que le hachage ?

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 :

MD2 : http://tools.ietf.org/html/rfc1319

MD4 : http://tools.ietf.org/search/rfc1320

MD5 : http://fr.wikipedia.org/wiki/MD5

SHA : http://fr.wikipedia.org/wiki/SHA-0

SHA1 : http://fr.wikipedia.org/wiki/SHA-1

SHA2 : http://fr.wikipedia.org/wiki/SHA-2

Whirlpool : http://www.seas.gwu.edu/~poorvi/Classes/CS381_2007/Whirlpool.pdf

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 :

SELECT md5(E'\\xd131dd02c5e6eec4693d9a0698aff95c2fcab58712467eab4004583eb8fb7f8955ad340609f4b30283e488832571415a085125e8f7cdc99fd91dbdf280373c5bd8823e3156348f5bae6dacd436c919c6dd53e2b487da03fd02396306d248cda0e99f33420f577ee8ce54b67080a80d1ec69821bcb6a8839396f9652b6ff72a70'::bytea)
UNION ALL
SELECT md5(E'\\xd131dd02c5e6eec4693d9a0698aff95c2fcab50712467eab4004583eb8fb7f8955ad340609f4b30283e4888325f1415a085125e8f7cdc99fd91dbd7280373c5bd8823e3156348f5bae6dacd436c919c6dd53e23487da03fd02396306d248cda0e99f33420f577ee8ce54b67080280d1ec69821bcb6a8839396f965ab6ff72a70'::bytea)

Pour MS SQL Server :

SELECT HASHBYTES('md5', 0xd131dd02c5e6eec4693d9a0698aff95c2fcab58712467eab4004583eb8fb7f8955ad340609f4b30283e488832571415a085125e8f7cdc99fd91dbdf280373c5bd8823e3156348f5bae6dacd436c919c6dd53e2b487da03fd02396306d248cda0e99f33420f577ee8ce54b67080a80d1ec69821bcb6a8839396f9652b6ff72a70)
UNION ALL
SELECT HASHBYTES('md5', 0xd131dd02c5e6eec4693d9a0698aff95c2fcab50712467eab4004583eb8fb7f8955ad340609f4b30283e4888325f1415a085125e8f7cdc99fd91dbd7280373c5bd8823e3156348f5bae6dacd436c919c6dd53e23487da03fd02396306d248cda0e99f33420f577ee8ce54b67080280d1ec69821bcb6a8839396f965ab6ff72a70)

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 :

la même clef servant à crypter et décrypter, on parle alors de chiffrement symétrique (il faut garder sa clef secrète)

une clef sert à chiffrer une autre à déchiffrer, on parle alors de chiffrement asymétrique (on peut rendre publique l’une des deux 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) :

symétrique : DES (56 bits), TRIPLE_DES (128 ou 192 bits), RC2, RC4, RC4_128 (128 bits), AES (128 à 256 bits)

asymétrique : RSA_512 (512 bits), RSA_1024 (1024 bits), RSA_2048 (2048 bits)

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 :

la découverte de techniques d’attaques permettant de « casser » ou de semer le trouble concernant le hachage (par exemple la génération de collisions)

la liberté légale de crypter des données, introduite en droit français peu après la directive européenne 2000/31/CE du 8 juin 2000 sur le commerce électronique, suite à l’affaire Zimmermann et son outil PGP.

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 :

l’auteur calcule une valeurs de hachage par le biais de la fonction de hachage considérée puis crypte cette information de hachage qui constitue la signature du document électronique. Cette signature est incorporée au document.

lors de la réception le destinataire calcule une valeur de hachage sur le document sans tenir compte de la signature, puis décrypte la signature à l’aide de la clef publique. Si les deux valeurs (la signature incorporée et la signature nouvellement calculées) sont identiques, alors le document à toutes les chances d’être authentique.

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 cassage aisé du code, si les données ne sont pas « salées »

la rapidité d’accès à l’information

la volumétrie de stockage des données cryptées

la difficulté de recherches performantes

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 :

les clefs sont généralement stockées en fichiers sur le serveur et non dans la base et sont par conséquent lisible par tout utilisateur ayant accès au serveur;

le chiffrement n’est pas « salé » et par conséquent une attaque du code par analyse fréquentielle est possible;

ces serveurs ne permettent pas d’utiliser des boitiers de type HSM, qui s’avèrent particulièrement intéressant pour les données bancaires (code des cartes de paiement) ou de santé (données personnelles);

un service de chiffrement du stockage de type TDE n’est pas intégré dans de tels serveur ce qui fait par exemple qu’un fichier de données ou une sauvegarde volée donne tout le temps au voleur de déchiffrer par recoupement.

comme la clef ne figure pas dans la base, elle doit être transmise en clair dans les requêtes. Elle figure donc dans les routines (fonctions PG/PLSQL de PostGreSQL par exemple) comme dans les requêtes des appliciations clientes.

le code généré est généralement assez court et permet plus aisément une attaque

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

Avec PostGreSQL, extension pgcrypto avec algorithme AES :

CREATE EXTENSION pgcrypto;

CREATE TABLE T_NOM
(NOM VARCHAR(32),
NOM_CRYPTE bytea);

INSERT INTO T_NOM (NOM)
VALUES ('MARTIN'),
('DUPONT'),
('MARTIN'),
('DURAND');

Cryptage :

UPDATE T_NOM
SET NOM_CRYPTE = encrypt(CAST(NOM AS bytea), 'Le petit chat est mort.', 'aes');

SELECT * FROM T_NOM;

NOM NOM_CRYPTE
---------- ---------------------------------------------------------------
MARTIN \212\306\335\270\27615\334\33021o\212\271\252a\277\302
DUPONT \343\331\307-\202\203\301|(\247M32+\177\301\265
MARTIN \212\306\335\270\27615\334\33021o\212\271\252a\277\302
DURAND 3513\252\23627^M21,3002]w\326\227

Décryptage :

SELECT NOM, CAST(decrypt(NOM_CRYPTE, 'Le petit chat est mort.', 'aes') AS VARCHAR(32)) AS NOM_CLAIR
FROM T_NOM;

NOM NOM_CLAIR
---------- ---------------------------------------------------------------
MARTIN MARTIN
DUPONT DUPONT
MARTIN MARTIN
DURAND DURAND

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 :

-- création d'une clef de cryptage de niveau base de données
-- permettant la génération de clefs de cryptage interne
CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'Le petit chat est mort.';
GO

-- création d'une clef de cryptage avec algorithme ASE clef à 256 bits
CREATE SYMMETRIC KEY MA_CLEF
WITH ALGORITHM = AES_256
ENCRYPTION BY PASSWORD = 'P@ssw0rd !';
GO

CREATE TABLE T_NOM
(NOM VARCHAR(32),
NOM_CRYPTE VARBINARY(256));

INSERT INTO T_NOM (NOM)
VALUES ('MARTIN'),
('DUPONT'),
('MARTIN'),
('DURAND');

Cryptage :

-- ouverture de la clef pour la session
-- peut être fait côté serveur dans un déclencheur FOR LOGON et dans ce cas
-- le mot de passe ne sera pas codé dans les applis ni transmis dans le réseau
OPEN SYMMETRIC KEY MA_CLEF
DECRYPTION BY PASSWORD = 'P@ssw0rd !';

-- la fonction KEY_GUID permet de retrouver la clef primaire informatique
-- (de type GUID) de la clef de cryptage pour pouvoir l'utiliser
UPDATE T_NOM
SET NOM_CRYPTE = ENCRYPTBYKEY(KEY_GUID('MA_CLEF'), NOM);

SELECT * FROM T_NOM;

NOM NOM_CRYPTE
------------ ------------------------------------------------------------------------------------------------------------
MARTIN 0x00AC31E101131E408D190F626A5F757801000000519DC1A3C61A63A66EA857F7E9BBE649E09989B0E718CDFE861BE27CFAEA68B8
DUPONT 0x00AC31E101131E408D190F626A5F7578010000000BECCA5469AFF7771675C1D9FB7103A1807FE2430FBF1922C56A990CBC3BA6FF
MARTIN 0x00AC31E101131E408D190F626A5F757801000000B496C2D5DC5D92D4303B05B86457042767CC4382F852B29BFA1B0A66BB566388
DURAND 0x00AC31E101131E408D190F626A5F757801000000121A2325A435CD72E830B255089C25CA24CF0A7FD2C693F66819FE5493FDD0F0

Décryptage :

-- la clef étant ouverte, on a pas besoin du mot de passe pour décryptage
SELECT NOM, CAST(DECRYPTBYKEY(NOM_CRYPTE) AS VARCHAR(32)) AS NOM_CLAIR
FROM T_NOM;

NOM NOM_CLAIR
------------ --------------
MARTIN MARTIN
DUPONT DUPONT
MARTIN MARTIN
DURAND DURAND

CLOSE SYMMETRIC KEY MA_CLEF;

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

Calculs SQL avec des dates : age exact révolu et anniversaires…

SQLpro — Wed, 05 Feb 2014 23:27:07 +0000

Parmi les requêtes les plus difficile à établir en SQL se trouve généralement les calculs temporels. Voici deux problématiques résolues, celle du calcul de l’âge révolu et celle de la recherche de personnes sont l’anniversaire est à souhaiter… pas si simple !

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

D’abord la table :

CREATE TABLE T_PERSONNE_PRS
(PRS_ID INT IDENTITY PRIMARY KEY,
PRS_DATE_NAISSANCE DATE)
GO

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…

DECLARE @D DATE = '1900-01-01';
WHILE @D <= CURRENT_TIMESTAMP
BEGIN
INSERT INTO T_PERSONNE_PRS VALUES (@D);
SET @D = DATEADD(DAY, 1, @D);
END;

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

WITH TN AS (SELECT 1 AS N
UNION ALL
SELECT N + 1
FROM TN
WHERE N < 24)
INSERT INTO T_PERSONNE_PRS
SELECT PRS_DATE_NAISSANCE
FROM TN
CROSS JOIN T_PERSONNE_PRS AS TP;

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) :

-- ceci est inexact... car imprécis jusqu'à 11 mois et 30 jours près !
SELECT *, DATEDIFF(YEAR, PRS_DATE_NAISSANCE, GETDATE()) AS AGE
FROM T_PERSONNE_PRS;

-- ceci est inexact... car imprécis jusqu'à 30 jours près !
SELECT *, DATEDIFF(MONTH, PRS_DATE_NAISSANCE, GETDATE()) / 12 AS AGE
FROM T_PERSONNE_PRS;

-- ceci est inexact... car imprécis à 1 jours près !
SELECT *, FLOOR(DATEDIFF(DAY, PRS_DATE_NAISSANCE, GETDATE()) / 365.25) AS AGE
FROM T_PERSONNE_PRS;

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

Requête 1 :

SELECT *
FROM T_PERSONNE_PRS
WHERE ((MONTH(PRS_DATE_NAISSANCE) -1 ) * 31 + (DAY(PRS_DATE_NAISSANCE) -1 ) ) % (31 * 12)
BETWEEN ((MONTH('2013-11-20') - 1 ) * 31 + (DAY('2013-11-20') - 1) ) % (31 * 12)
AND ((MONTH('2013-12-10') - 1 ) * 31 + (DAY('2013-12-10') + 371) ) % (31 * 12);

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 :

-- les personnes qui ont leur date d'anniversaire aujourd'hui
SELECT *
FROM T_PERSONNE_PRS
WHERE MONTH(PRS_DATE_NAISSANCE) = MONTH(GETDATE())
AND DAY(PRS_DATE_NAISSANCE) = DAY(GETDATE());

-- les personnes qui ont leur date de naissance dans 15 jours
SELECT *
FROM T_PERSONNE_PRS
WHERE MONTH(PRS_DATE_NAISSANCE) = MONTH(DATEADD(DAY, 15, GETDATE()))
AND DAY(PRS_DATE_NAISSANCE) = DAY(DATEADD(DAY, 15, GETDATE()));

-- les personnes qui ont leur date d'anniversaire dans le mois courant
SELECT *
FROM T_PERSONNE_PRS
WHERE MONTH(PRS_DATE_NAISSANCE) = MONTH(GETDATE());

-- les personnes qui ont leur date d'anniversaire dans le mois suivant le mois courant
SELECT *
FROM T_PERSONNE_PRS
WHERE MONTH(PRS_DATE_NAISSANCE) = (MONTH(GETDATE()) + 1) % 13 + MONTH(GETDATE()) / 12;
-- notez le + 1 pour rechercher le mois suivant

-- les personnes qui ont leur date d'anniversaire dans le 6e mois suivant le mois courant
SELECT *
FROM T_PERSONNE_PRS
WHERE MONTH(PRS_DATE_NAISSANCE) = (MONTH(GETDATE()) + 6) % 13 + MONTH(GETDATE()) / 12;
-- notez le + 6...

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

Voici tout d’abord quelques cas triviaux :

-- exemple 1 : 20 février / 10 mars
SELECT *
FROM T_PERSONNE_PRS
WHERE MONTH(PRS_DATE_NAISSANCE) * 31
+ DAY(PRS_DATE_NAISSANCE) >= MONTH('2014-02-20') * 31
+ DAY('2014-02-20')
AND MONTH(PRS_DATE_NAISSANCE) * 31
+ DAY(PRS_DATE_NAISSANCE) <= MONTH('2014-03-10') * 31
+ DAY('2014-03-10');

-- exemple 2 : 20 décembre / 10 janvier (an + 1)
SELECT *
FROM T_PERSONNE_PRS
WHERE MONTH(PRS_DATE_NAISSANCE) * 31
+ DAY(PRS_DATE_NAISSANCE) >= MONTH('2014-12-20') * 31
+ DAY('2014-12-20')
OR MONTH(PRS_DATE_NAISSANCE) * 31
+ DAY(PRS_DATE_NAISSANCE) <= MONTH('2015-01-10') * 31
+ DAY('2015-01-10');
-- notez la présence du OR à la place du AND, car nous avons changé d'année (l'intervalle s'est "retourné") !

Et maintenant la solution générique :

Requête 2

-- avec dates du 20 décembre au 10 janvier (an + 1)
SELECT *
FROM T_PERSONNE_PRS
WHERE (MONTH(PRS_DATE_NAISSANCE) * 31 + DAY(PRS_DATE_NAISSANCE) ) % (31 * 12)
BETWEEN (MONTH('2014-12-20') * 31 + DAY('2014-12-20')) % (31 * 12)
AND (MONTH('2015-01-10') * 31 + DAY('2015-01-10') + 372) % (31 * 12);

-- avec dates du 20 février au 10 mars
SELECT *
FROM T_PERSONNE_PRS
WHERE (MONTH(PRS_DATE_NAISSANCE) * 31 + DAY(PRS_DATE_NAISSANCE) ) % (31 * 12)
BETWEEN (MONTH('2014-02-20') * 31 + DAY('2014-02-20')) % (31 * 12)
AND (MONTH('2014-03-10') * 31 + DAY('2014-03-10') + 372) % (31 * 12);

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

Tri combiné dans un arbre intervallaire

SQLpro — Thu, 18 Apr 2013 07:42:23 +0000

Trier des données dans le sens de l’arborescence et quand elle sont aux même niveau (frères) par ordre alphabétique (tri mixte arbre et alfa) est difficile à réaliser dans un arbre modélisé par intervalle. Mais le principe est assez simple. Il suffit de composer une nouvelle colonne constitué d’une alternance de nœud et d’ordre alphabétique relatif dans la fratrie, et de trier dessus. Voici comment faire. Cette technique s’appelle en anglais « sibling ordering ».

1 – LE PROBLÈME

Voici notre jeu de test :

Tout d’abord la table

CREATE TABLE T_VEHICULE_VHC
(VHC_ID INTEGER NOT NULL PRIMARY KEY,
VHC_BG INTEGER,
VHC_BD INTEGER,
VHC_NIVEAU SMALLINT,
VHC_NOM VARCHAR(16));

Et ses données :

INSERT INTO T_VEHICULE_VHC VALUES ( 1, 1, 26, 0, 'ALL');
INSERT INTO T_VEHICULE_VHC VALUES ( 2, 2, 7, 1, 'SEA');
INSERT INTO T_VEHICULE_VHC VALUES ( 3, 8, 19, 1, 'EARTH');
INSERT INTO T_VEHICULE_VHC VALUES ( 4, 20, 25, 1, 'AIR');
INSERT INTO T_VEHICULE_VHC VALUES ( 5, 3, 4, 2, 'SUBMARINE');
INSERT INTO T_VEHICULE_VHC VALUES ( 6, 5, 6, 2, 'BOAT');
INSERT INTO T_VEHICULE_VHC VALUES ( 7, 9, 10, 2, 'CAR');
INSERT INTO T_VEHICULE_VHC VALUES ( 8, 11, 16, 2, 'TWO WHEELS');
INSERT INTO T_VEHICULE_VHC VALUES ( 9, 17, 18, 2, 'TRUCK');
INSERT INTO T_VEHICULE_VHC VALUES (10, 21, 22, 2, 'ROCKET');
INSERT INTO T_VEHICULE_VHC VALUES (11, 23, 24, 2, 'PLANE');
INSERT INTO T_VEHICULE_VHC VALUES (12, 12, 13, 3, 'MOTORCYCLE');
INSERT INTO T_VEHICULE_VHC VALUES (13, 14, 15, 3, 'BICYCLE');

Premier essai :

Une simple requête telle que celle-ci :

SELECT CAST(SPACE(VHC_NIVEAU) + VHC_NOM AS VARCHAR(32)) AS NOM_IDENTE,
VHC_ID, VHC_BG, VHC_BD, VHC_NIVEAU
FROM T_VEHICULE_VHC
ORDER BY VHC_BG;

Donne un résultat insatisfaisant :

NOM_IDENTE VHC_ID VHC_BG VHC_BD VHC_NIVEAU
-------------------------------- ----------- ----------- ----------- ----------
ALL 1 1 26 0
SEA 2 2 7 1
SUBMARINE 5 3 4 2
BOAT 6 5 6 2
EARTH 3 8 19 1
CAR 7 9 10 2
TWO WHEELS 8 11 16 2
MOTORCYCLE 12 12 13 3
BICYCLE 13 14 15 3
TRUCK 9 17 18 2
AIR 4 20 25 1
ROCKET 10 21 22 2
PLANE 11 23 24 2

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 :

CREATE TABLE T_VEHICULE2_VHC
(VHC_ID INTEGER NOT NULL PRIMARY KEY,
VHC_BG INTEGER,
VHC_BD INTEGER,
VHC_NIVEAU SMALLINT,
VHC_NOM VARCHAR(16));

Les données réarrangées :

INSERT INTO T_VEHICULE2_VHC VALUES ( 1, 1, 26, 0, 'ALL');
INSERT INTO T_VEHICULE2_VHC VALUES ( 2, 20, 25, 1, 'SEA');
INSERT INTO T_VEHICULE2_VHC VALUES ( 3, 8, 19, 1, 'EARTH');
INSERT INTO T_VEHICULE2_VHC VALUES ( 4, 2, 7, 1, 'AIR');
INSERT INTO T_VEHICULE2_VHC VALUES ( 5, 23, 24, 2, 'SUBMARINE');
INSERT INTO T_VEHICULE2_VHC VALUES ( 6, 21, 22, 2, 'BOAT');
INSERT INTO T_VEHICULE2_VHC VALUES ( 7, 9, 10, 2, 'CAR');
INSERT INTO T_VEHICULE2_VHC VALUES ( 8, 13, 18, 2, 'TWO WHEELS');
INSERT INTO T_VEHICULE2_VHC VALUES ( 9, 11, 12, 2, 'TRUCK');
INSERT INTO T_VEHICULE2_VHC VALUES (10, 5, 6, 2, 'ROCKET');
INSERT INTO T_VEHICULE2_VHC VALUES (11, 3, 4, 2, 'PLANE');
INSERT INTO T_VEHICULE2_VHC VALUES (12, 16, 17, 3, 'MOTORCYCLE');
INSERT INTO T_VEHICULE2_VHC VALUES (13, 14, 15, 3, 'BICYCLE');

La requête :

SELECT CAST(SPACE(VHC_NIVEAU) + VHC_NOM AS VARCHAR(32)) AS NOM_IDENTE,
VHC_ID, VHC_BG, VHC_BD, VHC_NIVEAU
FROM T_VEHICULE2_VHC
ORDER BY VHC_BG;

Le résultat :

NOM_IDENTE VHC_ID VHC_BG VHC_BD VHC_NIVEAU
-------------------------------- ----------- ----------- ----------- ----------
ALL 1 1 26 0
AIR 4 2 7 1
PLANE 11 3 4 2
ROCKET 10 5 6 2
EARTH 3 8 19 1
CAR 7 9 10 2
TRUCK 9 11 12 2
TWO WHEELS 8 13 18 2
BICYCLE 13 14 15 3
MOTORCYCLE 12 16 17 3
SEA 2 20 25 1
BOAT 6 21 22 2
SUBMARINE 5 23 24 2

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 :

--===========================================================================--
-- Masque de caractères avec fusion alignée
--===========================================================================--
CREATE FUNCTION [F_PADMASK](@DATA NVARCHAR(1024),
@MASK NVARCHAR(1024),
@ALIGN CHAR(6))
RETURNS NVARCHAR(1024)
AS
/******************************************************************************
* Fonction de masque pour une donées polymorphe retournée en chaine de car. *
*******************************************************************************
* Fred. Brouard - http://sqlpro.developpez.com - www.sqlspot.com - 2012-07-12 *
*******************************************************************************
* Fusionne une donnée chaine avec un masque aligné à droite ou à gauche *
* Exemples : *
* SELECT dbo.F_PADMASK('ABC', '*****', 'LEFT' ) --> 'ABC**' *
* SELECT dbo.F_PADMASK(123, '00000', 'RIGHT') --> '00123' *
* SELECT dbo.F_PADMASK('ABCDEFG', '***', 'LEFT') --> 'EFG' *
* SELECT dbo.F_PADMASK('ABCDEFG', '***', 'RIGHT') --> 'ABC' *
******************************************************************************/
BEGIN
IF @MASK IS NULL RETURN '';
IF @DATA IS NULL RETURN @MASK;
IF UPPER(@ALIGN) IN ('RIGHT', 'DROIT', 'DROITE')
SET @ALIGN = 'RIGHT'
ELSE
SET @ALIGN = 'LEFT';
-- masque avec alignement à gauche (alpha)
IF @ALIGN = 'LEFT'
BEGIN
IF LEN(@MASK) > LEN(@DATA)
SET @DATA = @DATA + SUBSTRING(@MASK, LEN(@DATA) + 1, LEN(@MASK) - LEN(@DATA));
IF LEN(@MASK) LEN(@DATA)
SET @DATA = SUBSTRING(@MASK, 1, LEN(@MASK) - LEN(@DATA)) + @DATA;
IF LEN(@MASK) < LEN(@DATA)
SET @DATA = SUBSTRING(@DATA, LEN(@DATA) - LEN(@MASK) + 1, LEN(@MASK));
END;
RETURN @DATA;
END
GO

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 :

WITH
TA AS -- crée un indice numérique global d'ordonnancement alphabétique des libellés et le transforme en chaine complété avec des zéros
(SELECT VHC_ID, VHC_BG, VHC_BD, VHC_NIVEAU, VHC_NOM,
dbo.F_PADMASK(CAST(ROW_NUMBER() OVER(ORDER BY VHC_NOM) AS VARCHAR(10)), '00000000000', 'RIGHT') AS ORDRE
FROM T_VEHICULE_VHC),
T0 AS -- concatène un mixte de chemin et d'indice alphabétique dans une colonne intitulée PATH_MIXTE
(SELECT VHC_ID, VHC_BG, VHC_BD, VHC_NIVEAU, VHC_NOM, ORDRE,
CAST(dbo.F_PADMASK(VHC_NOM, '****************', 'LEFT') + ORDRE AS NVARCHAR(max)) AS PATH_MIXTE
FROM TA
WHERE VHC_NIVEAU = 0
UNION ALL
SELECT T1.VHC_ID, T1.VHC_BG, T1.VHC_BD, T1.VHC_NIVEAU, T1.VHC_NOM, T1.ORDRE,
T0.PATH_MIXTE + dbo.F_PADMASK(T1.VHC_NOM, '****************', 'LEFT') + T1.ORDRE
FROM TA AS T1
INNER JOIN T0
ON T1.VHC_NIVEAU = T0.VHC_NIVEAU + 1
AND T1.VHC_BG > T0.VHC_BG
AND T1.VHC_BD < T0.VHC_BD)
SELECT CAST(SPACE(VHC_NIVEAU) + VHC_NOM AS VARCHAR(32)) AS NOM_IDENTE,
VHC_ID, VHC_BG, VHC_BD, VHC_NIVEAU, PATH_MIXTE
FROM T0
ORDER BY PATH_MIXTE;

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 :

NOM_IDENTE VHC_ID VHC_BG VHC_BD VHC_NIVEAU PATH_MIXTE
------------------- ----------- ----------- ----------- ---------- ------------------------------------------------------------------------------------------------------------
ALL 1 1 26 0 ALL*************00000000002
AIR 4 20 25 1 ALL*************00000000002AIR*************00000000001
PLANE 11 23 24 2 ALL*************00000000002AIR*************00000000001PLANE***********00000000008
ROCKET 10 21 22 2 ALL*************00000000002AIR*************00000000001ROCKET**********00000000009
EARTH 3 8 19 1 ALL*************00000000002EARTH***********00000000006
CAR 7 9 10 2 ALL*************00000000002EARTH***********00000000006CAR*************00000000005
TRUCK 9 17 18 2 ALL*************00000000002EARTH***********00000000006TRUCK***********00000000012
TWO WHEELS 8 11 16 2 ALL*************00000000002EARTH***********00000000006TWO WHEELS******00000000013
BICYCLE 13 14 15 3 ALL*************00000000002EARTH***********00000000006TWO WHEELS******00000000013BICYCLE*********00000000003
MOTORCYCLE 12 12 13 3 ALL*************00000000002EARTH***********00000000006TWO WHEELS******00000000013MOTORCYCLE******00000000007
SEA 2 2 7 1 ALL*************00000000002SEA*************00000000010
BOAT 6 5 6 2 ALL*************00000000002SEA*************00000000010BOAT************00000000004
SUBMARINE 5 3 4 2 ALL*************00000000002SEA*************00000000010SUBMARINE*******00000000011

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