Discussion :

[Sparktacus]

Bonjour à tous ,

Je suis actuellement en train de générer une base de données Mysql à partir de divers fichier xml. Je ne sais pas encore combien de centaines de Mo ça va faire, mais ça promet d'être lourd.
Il va y avoir un nombre de colonnes plutôt important dont je génère la liste avec un petit script php.
Je me suis vite rendu compte qu'il sera trop fastidieux de "deviner" colonne par colonne quel est le type de champ nécessaire (INT, VACHAR, FLOAT, ...).

Puis je me suis dis, pourquoi ne pas mettre le même type partout, du genre VACHAR(255), faire mon importation et analyser a posteriori le contenu pour déterminer le meilleur type.

J'ai cherché un logiciel qui pourrait faire ça, mais je ne trouve pas. Je dois dire que ça m'étonne, la réalisation d'un tel outil me parait à la porté d'un bon développeur (regarder si c'est du contenu numérique, entier, UNSIGNED, alpha-numérique, la plus grande valeur de champs de la colonne en octets, etc ...).

Donc au final je pense que ça doit exister, mais que je n'ai pas trouvé. Je me demande même pourquoi il n'y a pas directement une commande SQL pour ça.

Pouvez-vous m'éclairer ?

[CinePhil]

Puisque tu veux utiliser un SGBD au lieu d'un fichier XML, profites-en pour construire une vraie base de données relationnelle.

Ton petit programme te permet d'extraire les nœuds principaux qui deviendront potentiellement des tables et les attributs de ces nœuds qui deviendront potentiellement des colonnes mais tu vas avoir des redondances de données si tu te contentes d'une aussi simple transformation.

Comme dans l'autre discussion, tu dis que tu peux avoir des nœuds avec un nombre d'attributs différent pour une même valeur de nœuds, tu traduis cela par mettre la colonne manquante à NULL lorsque l'attribut A n'est pas présent dans un nœud N2 alors qu'il est présent dans le nœud N1. Tu vas alors polluer ta BDD du bonhomme NULL, ce qui nuit aux performances quand le volume de données devient important, ce qui semble être le cas d'après ce que tu as écrit.

Je te recommande donc, à partir de ta liste de nœuds et d'attributs, de procéder à la modélisation de ta base de données en cherchant les associations existantes entre les nœuds et en détectant les attributs qui ont des valeurs prises dans une liste limitée.
Pour ce dernier point, dans ton exemple de l'autre discussion avec les bateaux, tu devrais faire une table pour les couleurs afin d'éviter de répéter "bleu" pour chaque bateau bleu, surtout que ce "bleu" pourrait potentiellement être écrit aussi "Bleue", "Blue" ou je ne sais quelle autre orthographe pour une valeur qui devrait être identique.
Le cas le plus typique que je cite en exemple est celui des villes telles que "Saint-Étienne" qui peut être écrite aussi "St Etienne", "Saint Etienne", "Saint-Etienne", "St Étienne"...

Quant à ta question pour déterminer automatiquement le bon type de la colonne (et pas champ ! ), il serait plus facile je pense de le faire à partir du XML en PHP plutôt qu'en SQL, en tout cas pas avec une requête simple mais avec une procédure stockée. Et si tu modélises la BDD, tu trouveras toi-même les bons types de données.

Bon courage !

Si tu as besoin d'aide pour la modélisation, adresse toi au forum Schéma.

[Sparktacus]

Bonjour,

Tu vas alors polluer ta BDD du bonhomme NULL, ce qui nuit aux performances quand le volume de données devient important, ce qui semble être le cas d'après ce que tu as écrit.

Ton observation sur les valeur NULL est tout à fait exacte.

Je te recommande donc, à partir de ta liste de nœuds et d'attributs, de procéder à la modélisation de ta base de données en cherchant les associations existantes entre les nœuds et en détectant les attributs qui ont des valeurs prises dans une liste limitée.

Mais je ne peux rien y faire. Je lis et relis ce que tu me dis mais je ne vois pas où tu veux en venir. Je ne vais pas créer plusieurs tables pour mettre les colonnes les moins souvent à NULL ensemble, si ? C'est ce que tu suggères ? Mettre les colonnes 1 à 10 dans la table1 puis de 11 à 30 dans la table2. Me retrouver avec une table découpée en plusieurs est certes plus léger (parce que NULL est si lourd que ça ?) mais certainement bien moins pratique. Plus tard, je récupèrerais les données par jointure, si je dois aller les chercher sur plusieurs table je n'imagine même pas la tête des dites requêtes et de leur lourdeur potentielle. Si je cherche la valeur de la colonne C, il faudra que je cherche dans quelle table je l'ai mise. La table1 retournera toujours quelque chose, mais pas forcément les tables supplémentaires dans lesquelles il faudra quand même exécuter la requête si je récupère 'tout'.

Un .xml/1er nœud = table
2ème nœud = ligne
Le contenu de chaque nœud génère une colonne par balise (ce que tu appelles attribut je pense, pour moi un attribut c'est dans les chevrons d'une balise sous forme de attribut="valeur", c'est comme ça que je le comprends, à tort peut être).

Quant à ta question pour déterminer automatiquement le bon type de la colonne (et pas champ ! ), il serait plus facile je pense de le faire à partir du XML en PHP plutôt qu'en SQL, en tout cas pas avec une requête simple mais avec une procédure stockée. Et si tu modélises la BDD, tu trouveras toi-même les bons types de données.

Finalement comme je n'ai rien trouvé (programme, script PHP), je génère une table avec toutes les colonnes en type TEXT, ensuite j'importe les données, j'analyse le contenu ligne par ligne, colonne par colonne, pour déterminer les types (TINYINT/.../BIGINT, FLOAT, VARCHAR, quelques ENUM, exceptionnellement TEXT). Puis un check de la valeur la plus grande pour la taille. Là j'en suis à l'écriture du script pour déterminer les float, je fais un tout petit blocage donc je vais écrire un autre topic à ce sujet, ensuite j'attaque le type CHAR et j'aurais fini .... cette étape.

Je suis toujours super surpris que de tel outil n'existe pas.

En tous cas merci de ne pas avoir laissé le sujet sans réponse

[CinePhil]

Mettre les colonnes 1 à 10 dans la table1 puis de 11 à 30 dans la table2

Table1 ou 2, colonne 1 ou N, c'est trop abstrait.

La modélisation consiste à représenter schématiquement un domaine sémantique.
Je reprends ton exemple de ta première discussion :

Code XML :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
<bateau>
	<couleur>bleu</couleur>
	<longueur>10</longueur>
	<mat>1</mat>
</bateau>
<bateau>
	<couleur>rouge</couleur>
	<longueur>10</longueur>
	<moteur>1</moteur>
</bateau>
<bateau>
	<couleur>blanc</couleur>
	<longueur>15</longueur>
</bateau>
<bateau>
	<couleur>rouge</couleur>
	<longueur>50</longueur>
	<mat>3</mat>
	<canot>1</canot>
</bateau>

On parle ici de "bateau", ce qui constitue une première entité type.
Le bateau a une couleur et la liste des couleurs semble limitée. Il est donc souhaitable de créer une entité type "couleur" et de l'associer à "bateau".

La règle de gestion entre les deux peut être la suivante :
Un bateau a une couleur et une couleur peut être celle de plusieurs bateaux.

Ce qui donne le MCD suivant :
bateau -1,1----avoir----0,n- couleur

Et ce MCD entrainera la création des tables suivantes :
tr_couleur_clr (clr_id, clr_nom...)
te_bateau_bat (bat_id, bat_id_couleur...)

La longueur est une quantité propre à tous les bateaux et peut donc être une propriété de l'entité type "bateau" et une colonne de la table des bateaux.
Idem pour moteur, mat, canot. Les bateaux sans moteur auront la colonne bat_moteur à 0, les bateaux sans mat auront la colonne bat_mat à 0...

Maintenant, on peut aussi typer les bateaux et définir par exemple que l'information intéressante pour un cargo sera son tonnage et que l'information intéressante pour un paquebot sera son nombre de passagers maxi. On peut alors faire un héritage :
cargo -(1,1)----être----0,1- bateau
paquebot -(1,1)----être----0,1---|

Ce qui donne les tables suivantes :
te_bateau_bat (bat_id, bat_id_couleur, [autres colonnes communes à tous les bateaux]...)
th_cargo_crg (crg_id_bateau, crg_tonnage, [autres colonnes spécifiques aux cargos])
th_paquebot_pqb (pqb_id_bateau, pqb_nb_passagers_max, [autres colonnes spécifiques aux paquebots])

Voilà comment, à partir d'un fichier XML contenant des données non typées, on peut, par raisonnement, aboutir à un modèle de données relationnel typé.

Il existe d'autres modèles intéressants. Par exemple pour les entités types à nombre de propriétés variables, la modélisation par métadonnées qui s'apparente fortement au XML dans son principe. Ou encore, pour les entités hiérarchiques, la modélisation d'arbre intervallaire.