Discussion :

[Evocatii]

Bonsoir,

Je sais que les puristes du SQL vont hurler... Mais je demandais s'il était possible d'ajouter des données en début de table ?

Quand on fait un SELECT * FROM TABLE, sans préciser la clause ORDER BY, MySQL retourne les résultats dans l'ordre où les enregistrements ont été inséré et cette petite subtilité peut s'avérer pratique quelques fois...

Merci pour votre aide !

[CinePhil]

Une table est comme un sac de billes. Quand tu insères des billes dans un sac, très rapidement, tu ne sais plus quelle est la première, la 12ème ou la dernière bille insérée parce qu'elles sont mélangées.
Une table, c'est pareil. Tu y insères des lignes et il n'y a pas de début, de milieu ou de fin de table.
Dis-nous plus précisément pourquoi tu veux faire ça et nous pourrons t'aider à trouver d'autres méthodes pour obtenir le résultat que tu cherches.

[Evocatii]

En fait, je possède une table répertoriant des villes du monde. Certaines villes utilisent des noms officiels, d'autres des noms alternatifs (par exemple dans la langue locale du pays ou un sous une forme simplifiée). On parle quand même de dizaines de millions de villes, ainsi par souci de simplicité et de performances, je me suis dit que ce serait plus pratique de tout mettre dans une même table.

Un utilisateur peut ensuite faire des recherches dans toutes ces villes et à partir de là, il est facile de retrouver le nom officiel en français : c'est la première ligne de résultat. Pas besoin de jointures, d'aller chercher dans différentes tables ou d'ajouter des champs supplémentaires.

J'ai pu faire ça en PHP, ça fonctionne et c'est très rapide, le problème, c'est que je dois regénérer ma base de données si je veux la mettre à jour, parce que MySql ne permet pas des insertions en début de table (ce qui est logique, comme tu me l'as très bien expliqué). C'est trop bancal comme solution ?

Pendant que j'y suis, une petite question quant à la modélisation de ces tables :

http://www.developpez.net/forums/d98...-geographique/

Un grand merci pour ton aide !

[CinePhil]

En fait, je possède une table répertoriant des villes du monde. Certaines villes utilisent des noms officiels, d'autres des noms alternatifs (par exemple dans la langue locale du pays ou un sous une forme simplifiée).

Il te faudrait donc logiquement deux tables :
- une avec les noms "officiels" qui contiendrait toutes les villes ;
- une autre avec les noms alternatifs des villes qui en ont.
Si le nom "officiel" est le nom français, tu pourrais ainsi avoir dans la table des villes officielles
id_ville, nom_ville
8124, 'Londres'

Et dans la table des noms alternatifs :
id_ville, id_langue, nom_ville_alternatif
8124, 2, 'London'

On parle quand même de dizaines de millions de villes, ainsi par souci de simplicité et de performances, je me suis dit que ce serait plus pratique de tout mettre dans une même table.

Ce n'est pas le nombre de lignes qui doit t'effrayer pour ne faire qu'une table.

Un utilisateur peut ensuite faire des recherches dans toutes ces villes et à partir de là, il est facile de retrouver le nom officiel en français : c'est la première ligne de résultat. Pas besoin de jointures, d'aller chercher dans différentes tables ou d'ajouter des champs supplémentaires.

Et moi je préconise justement de faire une table pour les noms alternatifs.

J'ai pu faire ça en PHP, ça fonctionne et c'est très rapide, le problème, c'est que je dois regénérer ma base de données si je veux la mettre à jour, parce que MySql ne permet pas des insertions en début de table (ce qui est logique, comme tu me l'as très bien expliqué). C'est trop bancal comme solution ?

Là je ne comprends pas le problème. Que veux-tu dire par "régénérer" ? Importer de nouveau toutes les données ? Tu peux les importer dans une table temporaire et mettre à jour la vraie table à partir des données de la nouvelle, comme ça tu ne perds pas les clés primaires.

Pendant que j'y suis, une petite question quant à la modélisation de ces tables :

http://www.developpez.net/forums/d98...-geographique/

Un grand merci pour ton aide !

Répondu là-bas.

[Evocatii]

Oki ! Oui, ça me semble une excellente solution ! Et en plus, ça évitera une redondance d'informations entre noms officiels et noms alternatifs (sachant que chaque ville possède également une latitude, longitude, ainsi que d'autres informations).

Merci beaucoup pour tes explications et ta patience !

[CinePhil]

En fait pour être vraiment internationnal, la table des villes ne devrait même pas comprendre le nom français mais seulement les autres attributs invariables quelle que soit la langue.

Ville (v_id, v_id_region, v_id_pays, v_latitude, v_longitude...)
Nom_ville_langue (nvl_id_ville, nvl_id_langue, nvl_nom)

Ainsi, tu peux avoir potentiellement autant de nvl_nom que de langues pour une même ville.
Exemple : Moscou en français, Moscow en anglais, Moskva en russe.

[Evocatii]

D'accord, je commence vraiment à comprendre comment modéliser une base de données. C'est de loin pas aussi évident qu'il n'y paraît ! En fait, on travaille avec des ensembles de données et pas avec des tableaux de données.

Si jamais, je laisse encore les liens vers les deux BD que j'utilise et qui sont ce que j'ai trouvé de plus complet, peut-être que ça servira à d'autres :

Pour tous les pays du monde (sauf US) :

http://earth-info.nga.mil/gns/html/namefiles.htm

Pour les US et territoires associés :

http://geonames.usgs.gov/domestic/download_data.htm

Pour la géolocalisation (payant) :

http://www.maxmind.com/

Enfin, je pense que c'est typiquement le genre d'application ou Memcache en soutien à MySQL fera des merveilles, vu que les données sont statiques !