[TNT] modification de la base de donnees

[Guillaume Lelarge]

Bonsoir à tous,

J'aurais tendance à dire comme Lionel et didbaba. Ne pas mettre le nom de la 
table sur les champs de celle-ci. C'est une information redondante et, comme 
toute information redondante, elle ne se vérifiera pas à chaque fois. 
J'aurais personnellement plutôt tendance à nommer chaque champ par rapport à 
sa fonction. Et pour être sûr qu'aucune fonction inadéquate n'est exécutée, 
je créerais un script par table dans lequel se feraient les opérations 
insert, update, delete.

Le Dimanche 26 Janvier 2003 01:10, vous avez écrit :
> Table pseudo:
>  - renommage uid en pseudo_id(16) unsigned
Je le remplacerais par id.
>  - suppression du champ 'comment' (inutilise)
OK.
>  - suppresion du champ 'photo' (inutilise)
OK.
>  - passage de 'fonction' a tinyint(1) unsigned
OK si on gère différents types de fonction. Au départ, ce champ devait 
permettre d'indiquer différentes fonctions (admin, traducteur, relecteur). Si 
ce champ doit toujours servir à différencier un admin d'un user lambda, il 
serait mieux de le remplacer par le champ 'admin' de type booléen.
>  - idem pour afficher
J'en ferais plutôt un booléen.
>  - passage de date_connect a derniere_connect datetime
OK.
>  - passage de nb_connect a int(10) unsigned
OK.

> Table demande:
Cette table est-elle toujours utile? Au départ, elle permettait d'enregistrer 
les demandes de pseudo et de mots de passe perdu. Actuellement, elle ne sert 
que pour les mots de passe perdus. Doit-on toujours enregistré ces demandes? 
Ou doit-on simplement les envoyer par mail?? Didbaba, comment la caverne 
gère-elle les 'plaintes' de mots de passe perdus??
>  - passage de uid a demande_id(16) unsigned
Je le renommerais id.
>  - passage de infossup a text(255)
OK.

> table dico:
>  - passage de termeuid a terme_id(16) unsigned
>  - passage de termeus a terme_us text(255)
>  - passage de termefr a terme_fr text(255)
>
Cette construction de table montre bien ce que je disais plus haut. En voyant 
cette construction, j'aurais tendance à me dire que la table s'appelle terme. 
Or elle s'appelle dico.
Donc, pour moi, il faudrait changer le nom de la table par terme et les 
colonnes devraient être id, us, fr.

> table livre:
>  - passage de id a livre_id int-16) unsigned
J'aurais conservé id.
>  - passage de titre a titre_livre varchar(32)
J'aurais conservé titre.
>  - passage de responsable a responsable_id int(16) unsigned
C'est le champ id de la table responsable ou c'est le champ responsable de la 
table id? :)
J'aurais remplacé par id_responsable car il s'agit d'un lien vers le champ id 
de la table des pseudo.

> table session:
>  - suppression, car devenue inutile avec les sessions php4 ?? (pas encore
> regarde)
>
OK.

> table traduction:
>  - passage de uid a traduc_id int(16) unsigned
id de type serial
>  - passage de chapitre a varchar(32)
>  - passage de nom a titre_livre varchar(32)
>  - passage de rep_en a rep_en varchar(255)
>  - passage de rep_fr a rep_fr varchar(255)
>  - passage de chemin a varchar(64)
>  - passage de datetrad a datetime
>  - passage de traducteur a traducteur_id int(16) unsigned
>  - passage de daterel a datetime
>  - passage de relecteur a relecteur_id int(16) unsigned
>  - passage de livre a livre_id int(16)
>
Je ne suis pas du tout d'accord sur cette table. Il me semble intéressant, 
voire nécessaire, d'avoir une table contenant la liste des répertoires pour 
éviter de grossir inutilement la table traduction comme c'est le cas 
actuellement. Renommer celle-ci en fichier serait nécessaire du coup. Il 
faudrait supprimer les champs repertoire, rep_en et rep_fr, et modifier le 
chapitre en id_repertoire (type int)
Bref, cette table doit être complètement remodelée.

> Voila, la liste est terminee.
Il aurait été intéressant que tu donnes un 'sens' à ces colonnes, simplement 
leur signification. Même si je sais personnellement à quoi elles servent, ce 
n'est pas obligatoirement le cas de tous.

> Cela amene un premier probleme, ecrire un script de conversion de
> l'ancienne base vers la nouvelle. Il est particulierement important, car il
> faudrait eviter de perdre des donnees.
>
Ce n'est pas complexe à faire, mais cela demande du temps et des tests. A mon 
sens, le mieux est de construire le script permettant l'abstraction de bases 
de données, puis le script de création des tables de la base, puis les 
scripts des tables (pour les insert, update, delete). Enfin, tu pourras 
commencer l'écriture du script de transfert.

Bonne chance ;-)


-- 
Guillaume.
-- 
Unsubscribe: send email to listar at linuxfromscratch.org
and put 'unsubscribe lfs-traducfr' in the subject header of the message