Aide pour la création d'une table Fermé

Question

Bonjour,

J'ai fais un script pour minimiser des URL (comme www.bit.ly) mais je dois faire une table MySQL, je ne sais pas si elle est bien adapté pour ce genre de citation.
Voici la structure que je désire :

id - unidid - url - timestamp - ip

id : ID primaire auto incrémentale (1,2,3...).
unidid : Une id unique faite en base 62 a partir du champ ID, elle comporte des chiffres et des lettres majuscules et minuscules.
url : Une URL très longue.
timestamp : Un timestamp.
id : Des IPv4 et IPv6

Voilà ce que je propose :
CREATE TABLE  'monsite'.'table' (
'id' INT NOT NULL AUTO_INCREMENT PRIMARY KEY ,
'uniqid' VARCHAR( 255 ) CHARACTER SET latin1 COLLATE latin1_general_cs NOT NULL ,
'url' TEXT CHARACTER SET latin1 COLLATE latin1_general_cs NOT NULL ,
'timestamp' VARCHAR( 255 ) NOT NULL ,
'ip' VARCHAR( 255 ) NOT NULL
) ENGINE = MYISAM ;

Capture d'écran : http://zupimages.net/up/1/2016567410.png

Est-elle correcte ?

Voici maintenant quelques questions :
1) unidid et url peuvent contenir des majuscules, minuscules et chiffres donc ils doivent être sensible à la casse, j'ai mis latin1_general_cs, c'est bon pour toutes les URL ? latin1_bin ne fonctionne pas avec les URL (j'obtiens [BLOB - 86o]) , c'est normal ?
2) Pour timestamp, vaut mieux mettre VARCHAR ou INT ?
3) INT accepte les nombre jusqu'à combien de caractères ?
4) Pour les VARCHAR je met toujours 255, le maximum, c'est grave ?

Voilà, j'attend vos réponses.

Merci d'avance.

mpmp93 · Answer

Bonsoir,

Je vous conseille très vivement l'encodage UTF-8

EN effet, il commence à y avoir des URLs en cyrillique. Donc, d'ici à ce qu'il y en ait dans d'autres alphabets...

Pour les timestamp, utilisez plutôt le type DATETIME. Même encombrement et plus lisible.

A+

Oduesp · Answer

Salut,
L'analyse doit être fonction du système d'information et non du code, risque de base à jeter dés qu'on veut rajouter quelque chose ou de fonctionnement tellement chaotique(risque d'erreur, lenteur ou complexité inutile) qu'il vaut mieux revenir au stylo et au papier...

Je ne connaît pas votre besoin et je ne sait pas si un fichier htaccess suffirait ou simplement un code pour transformer l'url mais ça me sembles plus adpaté vu votre demande qu'une base d'une table(ça n'existe quasiment pas ça).

Quelques remarques si on suit la méthode Merise(cocorico pour une fois que quelque chose en informatique est français on va pas se gêner de l'utiliser):

uniqid: à quoi sert ce champ? Si on suit la méthode Merise c'est une donnée calculable, donc une erreur de la mettre. La conversion en base 62 peut très bien se faire hors de la base. Vous pouvez par contre mettre le rapport de conversion dans le dictionnaire des données(toutes les données utiles au système) afin que si vous changiez de système de conversion 



1)Mysql n'est pas sensible à la casse(par défaut):
http://dev.mysql.com/doc/refman/5.0/fr/case-sensitivity.html
Si vous voulez garder la casse je pense que le plus simple est de formater le texte. Perso j'obligerais toutes les url à ne contenir aucune majuscule, c'est une recommandations qui évite pas mal d'erreur à chercher pourquoi une page s'affiche pas alors qu'on a la bonne url et chercher un bout de temps avant de trouver qu'un boulet à mis une majuscule à un nom de fichier.

2)Pour un timestamp il vaut mieux mettre un timestamp(format). mpmp93 a raison c'est plus lisible en datetime mais il doit être complet et si nous voulons l'utiliser en tant que timestamp il faut le convertir. Le timestamp sera aussi plus simple à comparer à un autre je trouves puisqu'on reste en base 10 et on va pas s'embêter avec les mois, années, etc(sauf bien sûr pour l'affichage si on veut une date lisible par un humain).

3)Bon là je vous laisse chercher, essayez google: int + mysql

4)Pas du tout, c'est même une bonne chose pour éviter d'avoir une valeur tronquée et donc une table fausse.

http://dev.mysql.com/doc/refman/5.0/fr/char.html

mpmp93 · Answer

Bonjour,

Sur ce point: 4) Pour les VARCHAR je met toujours 255, le maximum, c'est grave ? 

En fait, il est conseillé de mettre les VARCHAR à la taille des données envisagées? Exemple:
 9 pour les numéros SIRET
 10 pour des numéros téléphones genre 0ZABPQMCDU
 5 pour des codes postaux français, etc...

Ce n'est pas grave de mettre systématiquement 255... mais, oui mais: le moteur mySQL fait transiter les données en mémoire vive. Pour ce faire, il réserve un tampon qui calcule nd enregistrements x taille des champs (cas des recherches sur champs non indexés). Les mécanismes au niveau code sont assez sophistiqués, mais une taille limitée à la taille des données améliore les performances. Sur des enregistrements de faible quantité (de l'ordre de quelques centaines à 1 million), on ne mesure pas trop les pertes de performances. Au-delà, l'écroulement des temps de réponse devient exponentiel au volume des données. Une simple jointure sur deux champs dont un n'est pas indexé = temps d'exécution d'une requête multiplié par 100!!!

Donc, je préconise:
 - si les données d'un champ ont une taille limite connue -> fixer VARCHAR à la taille maxi de ces données, en général multiple de 16 pour des données de taille variable, exemple 64 pour des noms de communes,
 - les données ont une taille quelconque, utiliser un LONGTEXT

Concernant l'encodage UTF8, je préconise de mettre systématiquement l'encodage de tous les champs texte en UTF8. Il faut également avoir les scripts php et templates html en UTF8. Voir ici:
http://html5.immo-scope.com/index.php?page=general/applisFullUtf8

C'est une tendance forte et qui résout beaucoup de problèmes d'accents et caractères spéciaux pouvant survenir.

A+

Aide pour la création d'une table

3 réponses

Discussions similaires