Erreur: 1071 Specified key was too long

[Alcius]

Bonjour,

J'ai une table dont les champs sont essentiellement des VARCHAR(255). Lorsque j'éssais de créer un index unique composé de plusieurs champs, j'obtiens l'erreur: 1071 Specified key was too long; max key length is 1000 bytes.

J'ai lu quelque part que cela est du au charset utf-8 qui occupe plus d'espace que le latin. Quelle est la différence entre les 2 charset latin et utf-8 ? Lequel dois-je utiliser ?

Merci pour vos réponses.

[CinePhil]

Commence déjà par te demander si tu as vraiment besoin de 255 caractères dans toutes ces colonnes !

On peut voir la structure de la table ?

[Alcius]

C'est justement difficile à savoir si j'ai besoin de 255 caractères par collone car je ne controle pas le contenu. Et pour etre sûr que toutes les données passeront, je prends 255.

Je développe en fait une application qui créé dynamiquement les tables qui doivent contenir des données qui peuvent etre des adresses IP, des dates, du texte très long, etc. Mais comme les tables sont créé dynamiquement, il est impossible de savoir que tel champ contiendra tel type de donnée. Je prend donc tout en VARCHAR(255).

Après, j'ai besoin de faire en sorte que une ligne déja enregistrée ne soit pas de nouveau enregistrée. C'est pour cela que je voudrais faire un index unique de tous les champs.

La structure de l'une des tables:

CREATE TABLE IF NOT EXISTS `log_w3svc1` (
`Nr` int(11) NOT NULL AUTO_INCREMENT,
`date` varchar(255) DEFAULT NULL,
`time` varchar(255) DEFAULT NULL,
`s_sitename` varchar(255) DEFAULT NULL,
`s_ip` varchar(255) DEFAULT NULL,
`cs_method` varchar(255) DEFAULT NULL,
`cs_uri_stem` varchar(255) DEFAULT NULL,
`cs_uri_query` varchar(255) DEFAULT NULL,
`s_port` varchar(255) DEFAULT NULL,
`cs_usrname` varchar(255) DEFAULT NULL,
`c_ip` varchar(255) DEFAULT NULL,
`cs(usr_agent)` varchar(255) DEFAULT NULL,
`sc_status` varchar(255) DEFAULT NULL,
`sc_substatus` varchar(255) DEFAULT NULL,
`sc_win32_status` varchar(255) DEFAULT NULL,
`Application` varchar(160) NOT NULL DEFAULT 'GestLog',
PRIMARY KEY (`Nr`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 AUTO_INCREMENT=2490 ;

Merci pour l'aide.

[CinePhil]

Les colonnes date et time ne devraient pas s'appeler comme ça parce que ce sont des mots du langage SQL.

Il existe les types DATE 'aaaa-mm-jj' TIME 'hh:mm:ss' et DATETIME 'aaaa-mm-jj hh:mm:ss'

s_ip : À moins que tu aies des IP V6, le format sera toujours au maximum '255.255.255.255' donc pas besoin de 255 caractères !

s_port : si c'est un port d'ordinateur, ça m'étonnerait qu'il y en ait à 255 caractères !

c_ip : idem s_ip

Et pour les autres, un username à 255 caractères, c'est potentiellement possible mais ça fait quand même beaucoup !

Je développe en fait une application qui créé dynamiquement les tables

Ca c'est pas bon du tout !
On définit la structure des données et on n'y touche plus qu'en cas de modification importante des besoins de l'application utilisatrice ou plus généralement du système d'informations.

Bref, grosses erreurs de conception dès le départ entraînent le problème auquel tu es confronté et pour lequel tu as lancé cette discussion !

[Alcius]

grosses erreurs de conception dès le départ entraînent le problème auquel tu es confronté

Non, il n'y a pas de 'grosses erreurs de conception'. Cette application DOIT créer dynamiquement les tables. Je sais qu'une IP, une date ou un port ne font pas plus de 20 caractères. Mais ça, c'est parce que la table est déjà créée que l'on sait que ce sont des dates ou des IP. Avant la création, on ne sais pas ce que c'est.

[sgdev]

Pour corriger ce problème, il suffit de passer tes tables /de les créer en innodb non pas MyISAM

[kedare]

D'ailleurs pour les IP il faut pas les stocker comme ça, mais utiliser les fonctions pour : http://dev.mysql.com/doc/refman/5.0/...tion_inet-aton

Et si, il y a bien erreur de conception

[Alcius]

OK, en supposant qu'il y ait erreur de conception, que proposez vous pour y remédier, ou qu'auriez vous fait ?

Car il faut bien comprendre qu'on ne connait pas d'avance le type des champs des tables.

Je vous explique ce que fait cette application. Elle permet de mieux 'reporter' les fichiers logs. Au lieu d'avoir des fichiers textes difficiles à lire et exploiter, cette application permet d'importer un fichier log, et enregistre automatiquement dans MySQL le contenu du fichier, et créant automatiquement la table et les champs du log. Après, l'exploitation est plus aisée en faisant des éditions par critères, de la recherche et de l'exportation Excel.

Merci encore pour vos contributions.

[kedare]

Tu peux pas faire un mapping selon le type de logs en utilisant les bon champs ?
Pour ce scénario, je suis pas sure qu'une base de données relationnelle soit très adapté, tu a regardé du coté des bases de données clé-valeurs type Cassandra ou MongoDB ?

[CinePhil]

Si j'en juges par la structure de la table que tu nous présentes, l'application sait quand même nommer correctement les colonnes, probablement parce que c'est l'entête du fichier de log.

Tu pourrais donc importer le fichier dans une table temporaire et ensuite transférer les données dans une structure normalisée.

Si l'entête du fichier, donc les colonnes des tables, sont toujours du type quelquechose_ip ou quelquechose_uri, date, time, il est assez facile de reconnaître par programme de quel type d'info il s'agit et de transférer les données dans des colonnes de type approprié.