Discussion :

[Korben-Dallas]

Correction effectuée, il n'y a donc plus de LIKE "update"

[ericd69]

je pense que rajouter une colonne de ton bool va vite résoudre ton pb sur le 1er...

faut que tu te mettes enfin à penser en informaticien...

une table performante n'est pas là pour être lu par un humain faut faire un choix...
les états pour le suivi peuvent être codés

• soit par un booléen
• soit par un enum mais je te le déconseille car ça utilise de base un int comme identifiant
• soit par une clé étrangère pointant sur une table les listant (le mieux, plus souple niveau changement, la référence a une taille que tu peux adapter)

pour le deuxième ta colonne est indexée?
fait voir le show create de la table serveur

[Korben-Dallas]

LOL Je pense informaticien mais pas forcément développeur tout du moins mal et encore moins spécialiste BDD

Sinon voici la table :

Code :

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
 
CREATE TABLE `t_global_serveurs` (
	`AdresseDebutPlage` VARCHAR(20) NULL DEFAULT NULL,
	`AdresseFinPlage` VARCHAR(20) NULL DEFAULT NULL,
	`Vide` VARCHAR(20) NULL DEFAULT NULL,
	`AdresseDNS` LONGTEXT NULL,
	`AdresseDebutPlage_Traitee` INT(11) UNSIGNED NOT NULL,
	`AdresseFinPlage_Traitee` INT(11) UNSIGNED NOT NULL,
	`Gestionnaire` VARCHAR(50) NOT NULL,
	`Serveur` VARCHAR(20) NOT NULL,
	INDEX `AdresseDebutPlage_Traitee` (`AdresseDebutPlage_Traitee`),
	INDEX `AdresseFinPlage_Traitee` (`AdresseFinPlage_Traitee`),
	INDEX `Gestionnaire` (`Gestionnaire`),
	INDEX `Serveur` (`Serveur`)
)
COLLATE='latin1_swedish_ci'
ENGINE=MyISAM
AUTO_INCREMENT=16847;

Je viens de voir ça, il est peut être plus judicieux de créer un index double sur les 2 colonnes AdresseDebut et Fin Plage Traitee


Après modification de la table à propos des index :

Code :

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
 
CREATE TABLE `t_global_serveurs` (
	`AdresseDebutPlage` VARCHAR(20) NULL DEFAULT NULL,
	`AdresseFinPlage` VARCHAR(20) NULL DEFAULT NULL,
	`Vide` VARCHAR(20) NULL DEFAULT NULL,
	`AdresseDNS` LONGTEXT NULL,
	`AdresseDebutPlage_Traitee` INT(11) UNSIGNED NOT NULL,
	`AdresseFinPlage_Traitee` INT(11) UNSIGNED NOT NULL,
	`Gestionnaire` VARCHAR(50) NOT NULL,
	`Serveur` VARCHAR(20) NOT NULL,
	INDEX `Gestionnaire` (`Gestionnaire`),
	INDEX `Serveur` (`Serveur`),
	INDEX `AdressePlage_Traitee` (`AdresseDebutPlage_Traitee`, `AdresseFinPlage_Traitee`)
)
COLLATE='latin1_swedish_ci'
ENGINE=MyISAM
AUTO_INCREMENT=16847;

[ericd69]

adresse varchar(20) y a rien qui te choque???... si je te dis int unsigned...

longtext pour une adresse dns....

vide varchar(20)????

faut simplement penser types de base que tu as dans tous les langages!!!
et ça va te simplifier la vie...

parfois penser trop haut niveau avec la souplesse que peuvent donner certains langages c'est bien au niveau conceptuel et abstraction... c'est pas du tout efficace pour autan...

l'idée est simple c'est pas un humain qui brasse les données c'est un processeur!!!

rien que dans tes csv tu transformes les adresses en d'entier 32 bit non signé en chaine pour les faire... traitement inutile...
après tu refais des traitements de conversion pour... rien...

quand tu lis une trame tcp/ip ça te viendrait pas à l'idée de stocker les ip avec 20 caractères... au lieu des 4 octets...

c'est la même réflexion

[Korben-Dallas]

Oui c'est vrai et c'est pour ça que toute la structure de ma BDD est en court de réflexion, justement pour remettre tout carré.
Lorsque j'ai créé la BDD, déjà elle n'était pas ce qu'elle est aujourd'hui (elle évoluait à la warrior au besoin sans réflexion approfondie par manque de temps) Et puis je n'y connaissais rien du tout, j'apprends au fur et à mesure que je développe cet outil, autant dire que les différents conseils recueillis ici me permettent d'évoluer et donc de modifier la BDD mais ces modifications ne peuvent pas être faites du jour au lendemain, non seulement il faut du temps mais en plus il faut revoir toute la structure ce qui n'est pas une mince affaire, mais j'y réfléchi.
Sinon pour tes remarques, je ne peux pas modifier les CSV avant leurs injections puisque ces imports ne sont que des exports (propriétaires) de différents serveurs qui sont ensuite réinjectés dans ma BDD (consolidée). Voire même des imports de fichiers que les différents gestionnaires mettent en place.
Les adresses IP sont donc forcément marquées en dure dans la BDD, c'est d'ailleurs pour ça que j'ai créé une colonne avec l'adresse IP modifiée en Entier.
Quant à la colonne "Vide", celle-ci ne sert à rien à part juste permettre l'import d'un champs vide ou pourri des différents CSV, cette colonne ne sert jamais dans les requêtes (sauf lors de l'import)

[CinePhil]

Dans ce genre de processus, je recommande :
1) d'avoir une BDD normalisée et optimisée au niveau des types des colonnes ;
2) d'importer les CSV dans des tables d'import temporaires ;
3) d'avoir une procédure qui transfère les données importées dans la BDD normalisée en transformant si nécessaire les types des données importées vers les bons types des colonnes devant les accueillir.

Ainsi, pas besoin de colonne "vide" qui n'est en fait pas exploitée, on ne travaille qu'avec des données propres et optimisées pour leur bonne interrogation.

D'une manière générale :
1) ne pas faire confiance aux données importées ;
2) donc toujours les contrôler afin de ne pas polluer la BDD ;
3) donc ne les enregistrer dans la vrai BDD qu'une fois validées.

[Korben-Dallas]

C'est ce que je fais mais c'est vrai aussi que je le fais en faisant un insert into complet et non colonne par colonne.
A l'origine j'importais tout dans la BDD sans utiliser de tables temporaires, ensuite l'outil évoluant et les traitements étant de plus en plus long j'ai donc créé les tables temporaires pour le prétraitement mais hélas sans avoir fait évoluer outre mesure la BDD mais comme je le disais cette évolution est en cours de réflexion.

[CinePhil]

C'est ce que je fais mais c'est vrai aussi que je le fais en faisant un insert into complet et non colonne par colonne.

Je n'ai pas dit qu'il faut faire ça colonne par colonne. Juste que toutes les colonnes importées ne vont pas forcément dans une seule table, qu'il peut y avoir des données inexploitables dans l'import, des données déjà présentes... Bref, faut faire le tri.

[Korben-Dallas]

Justement j'ai besoin de toutes les infos des différents CSV, mais ensuite il est clair qu'il faut faire un prétraitement lors de leurs imports afin d'optimiser au mieux la BDD.
Ha lala c'est tout un métier l'architecture de BDD et ce n'est pas le mien, je ne fais ça qu'en plus de mon temps de travail et comme je suis parti de Zéro... Je trouve qd même que pour un pure débutant je m'en suis pas trop mal tiré mais qu'au fur et à mesure l'expérience arrive et là les différentes modifications à apporter aussi

[ericd69]

les méthodes sont simples:

• utiliser un typage intelligent:
  
  • comme dans n'importe quelle application avoir un typage des données adapté (hein ! )
  • toujours utiliser des typages les plus compacts possibles
• normaliser intelligemment:
  
  • une colonne avec des valeurs non numériques relativement répétitives -> dans une table à part et sera récupéré par jointure
  • une ou des colonnes représentant une relation 0-n (ex une relation hierarchique) -> dans une table de liaison (ça accélèrera les recherche parent-enfant ou inverse) au lieu de trimbaler une concaténation de valeurs dans une colonne...
• des index intelligents comme on te la décris plus haut
• dans certain cas on pourra faire un partitionnement vertical pour dégager des colonnes lourdes (textes genre description, etc...) dans un table avec la même primary key si les autres colonnes sont intensément soumises à des traitements et les textes seulement à des affichages ponctuels
• un partitionnement horizontal (avec un sous-partitionnement souvent très utile) sera souvent une bonne chose sur les tables à très forte capacité (comme les logs par exemple)... mysql supporte diverses méthodes pour le faire, pas la peine de le faire à la main
• utiliser des procédures stockées peut apporter un gain substantiel de bande passante en encapsulant tous les traitements une isolation code appelant/sql) un gain considérable de sécurité voire de temps d'exécution

ci joint mon cours sur le procédural

[Korben-Dallas]

OK Cool !!
Merci pour ces infos et merci aussi pour ton cours je vais me regarder ça et essayer de m'en servir à l'avenir.