Discussion :

[redah75]

c'est cool, merci beaucoup, j'ai enfin presque fini cette 'maudite' table

juste pour ton info, j'ai enfin de compte cree une table speciale pour les titres car si je mets le champ titre ds la table 'langues' et qu'un titre francais a etait traduit en anglais, cela voudra dire que l'ouvrage existe en ces 2 langues alors que c'est faut, c'est juste le titre qui est traduit en 2 langues!!
sources(id, titre_serie_org, titre_serie_en, titre_serie_fr)
sources_titres(id_source, titre, titre_abrege, langue)

ca te parait toujours OK ???

j'aimerais aussi juste avoir 2 derniers conseils STP:
1- pour les langues, c'est mieux d'utiliser 'fr', 'en',.. ou plutot des identifiants??

2- concernant les volumes et numeros de revues, quelle est la meilleure facon de les gerer? j'ai pense a juste creer un champ 'volume' et 'numero' dans la table 'articles', au moment de la saisie je rentre le num et volume de la source. puis pour recuperer tous les num et volumes, je fais un SELECT DISTINCT....
ou vas tu plutot me dire de creer un champ volum et num dans la table ouvrages???

[ced]

Pour le modèle des titres, ça a l'air correct (tu vois, plus besoin d'aide ).

Pour les 2 autres "conseils" :
1/ c'est une question de goût personnel, mais je préfère les identifiants numériques (ils sont, je crois, plus simple à indexer pour le SGBD, mais ça je n'en suis pas sûr) ;
2/ il vaut mieux les mettre dans la table ouvrage. C'est une info d'ouvrage. Si tu le met dans la table article, 2 article d'un même volume et d'une même revue auront une info redondante, et c'est la galère à mettre à jour. Tu peux aussi avoir une table volume entre ouvrage (que j'assimile à une revue) et article. C'est encore ça le plus propre conceptuellement.

ced

[redah75]

tu vois, plus besoin d'aide

j'avoue que c'est un peu grace a toi ke je vois mieux les choses maintenant

1- OK, je mettrai les identifiants

2- je v reflechir a ce que tu m'as dit et te tiendrai au courant

[redah75]

je reviens rapidement vers toi

effectivement, la meilleure chose est de creer une table volume_numero reliee a ouvrages:
volume_numero(id_ouvrage, volume, numero)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
id_ouvrage | volume | numero
--------------------------------------
1001          1         1
1001          1         2
1001          1         3
1001          2         1
1001          2         2
...

mais j'ai parfois une exeption: 2 numeros peuvent sortir en meme temps (numero double), comment gerer ca???

[ced]

Ca ne change rien au modèle... Tu as bien 2 numéros distincts d'un même ouvrage, simplement ils ont la même date de parution, non ?
Ou alors, ils portent le même numéro ? Il te faut un moyen de gérer la distinction dans le schéma, par exemple par un indicateur de sous-numéro... Je ne sais pas trop, il faudrait un exemple...

ced

[redah75]

j'ai fait une grosse betise et je t'ai induis ds l'erreur, chui desole

voici un exemple sachant que j'ai un champ 'date_publication' dans la table 'ouvrages' :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
id_ouvrage | volume | numero
--------------------------------------
1001          1         1
1012          1         2
1012          1         3
1041          2         1
1078          2         2
...

et là l'ouvrage 1012 est sorti en numero double: numero 2 et 3 qu'en penses tu?


je ne sais pas si je l'ai pricise au depart, j'ai 2 types de sources: livres et revues. ds la table 'ouvrages' j'ai des champs comme cote, inventaire, ... qui ne conceranent que les 'livres', est ce que je peux les garder ds cette table qui contiendra des trous si la source est de type 'revue' ou vaaut il mieux creer une table complementaire qui contient que les champs propres aux livres qui sera reliee a 'ouvrages'???

P.S. je sais que tu devrais te dire que ca n'en finis jamais. et je t'en remercie ifiniment!

[ced]

et là l'ouvrage 1012 est sorti en numero double: numero 2 et 3 qu'en penses tu?

Ca semble correct, tu sais du coup distinguer les 2 numéros (et ils ont la même date, ce qui indique qu'il s'agit d'un numéro double).

je ne sais pas si je l'ai pricise au depart, j'ai 2 types de sources: livres et revues. ds la table 'ouvrages' j'ai des champs comme cote, inventaire, ... qui ne conceranent que les 'livres', est ce que je peux les garder ds cette table qui contiendra des trous si la source est de type 'revue' ou vaaut il mieux creer une table complementaire qui contient que les champs propres aux livres qui sera reliee a 'ouvrages'???

Non, ça ne pose pas de problème... A ton application de maintenir la cohérence sur les données à remplir en fonction des cas...

P.S. je sais que tu devrais te dire que ca n'en finis jamais. et je t'en remercie ifiniment!

J'osais pas le dire . Non, je plaisante .

C'est dur, la modélisation...

ced

[redah75]

Ok, merci beaucoup, maintenant je vais avancer un peu sur les formulaires...

je te dirai si je bloque sur autre chose (j'espere pas)

bonne soiree
Reda

[ced]

Pense au bouton si tout te semble résolu.
Merci et bon courage,

ced

[redah75]

meme si je peux te reposer une autre question ds qlq jours je clique sur 'resolu' ?

[ced]

A toi de voir, mais à priori oui (tu peux toujours enlever le résolu si tu as d'autres soucis ).

ced

[redah75]

Bonjour Ced, comment ca va?
je reveille ce post pour encore une petite question :

j'ai par exemple une table 'livres' avec les champs suivant: id, titre_en, titre_fr, resume_en, resume_fr, ...
sachant que titre_fr et resume_fr peuvent etre vide, est ce mieux de creer cette table de cette maniere:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
livres:
id, titre_en, titre_fr, resume_en, resume_fr, ...

ou plutot

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
livres:
id, titre_en, resume_en, ...
 
livres_details:
id_livre, titre_fr, resume_fr

ou encore

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
livres:
id, ...
 
livres_details:
id_livre, titre, resume, langue

je suis tres indecis et je ne sais quoi faire!
en general, quand on a une relation 1, 2, mieux vaut creer une table relationnelle ou juste cerrer les 2 champs sachant que l'un des 2 peut etre vide??

Merci merci mile fois

[Maljuna Kris]

aucune reponses???

Ce singulier pluriel dont tu affliges les réponses 'absentes' dénote une bonne dose d'optimisme.

Tout mettre dans une même table c'est créer inutilement des espaces de stockage qui contiendront NULL, et s'exposer à des déconvenues si, d'aventure, de nouvelles langues devaient apparaître dans le cahier des charges.

Multiplier les tables c'est s'exposer à une situation imprévue (nouvelle langue= nouvelle table, un peu comme supra)

Typer les enregistrements d'une colonne 'lang' c'est éviter ces écueils, mais c'est aussi ralentir les insertions, mises à jour et suppressions notamment pour la gestion des index.

Toutefois, j'opterais personnellement plutôt pour cette solution qui me semble plus pérenne et paramétrable pour les requêtes d'interrogation même si elle risque de pénaliser un peu les INSERT, UPDATE et DELETE.

[redah75]

merci pour ta reponse

dans mon cas, il y a UNIQUEMENT le francais et anglais!
quelle est alors la solution que tu me recommandes??

[Maljuna Kris]

Auras-tu des requêtes d'interrogation devant rapatrier les infos dans les deux langues pour chaque ligne ?
Si c'est le cas la première solution sera probablement plus performante.
En tout état de cause je crois que tu peux abandonner la deuxième solution qui présente les inconvénients des deux autres sans leurs avantages.
Bien sûr tout cela dépend aussi du volume envisagé des tables.

[redah75]

Auras-tu des requêtes d'interrogation devant rapatrier les infos dans les deux langues pour chaque ligne ?

desole, j'ai pas bien compris ta question!

Si c'est le cas la première solution sera probablement plus performante.

tu m'avais dit que c'etait pas performant comme solution puisqu'on y stocke des NULL...

[Maljuna Kris]

Je reformule donc, puisqu'apparemment je ne suis pas clair.
auras-tu besoin de faire quelque chose du genre

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

SELECT titre_en, titre_fr, resume_en, resume_fr....

Auquel cas, si tu choisis la solution 3 tu devras faire une auto-jointure de la table sur elle-même, alors qu'avec la solution 1 tu demanderas tout dans la même table.
Dans un cas comme dans l'autre tu pourras avoir des valeurs NULL selon que les colonnes n'auront pas été renseignées (cas 1) ou qu'il n'existera pas de ligne en correspondance (cas 2 et 3)
Quant à la performance, rappelons d'abord qu'il s'agit d'une notion toujours relative (voire parfois subjective), une solution peut être plus performante sous certains aspects qu'une autre qui sera plus performante pour d'autres aspects.
J'ai écrit

j'opterais personnellement

, si c'est pas de la subjectivité ça !

[redah75]

Biensur que je vais devoir faire des SELECTs sur les champs...

OK, je v reflechir sur le reste...

Merci

[ced]

Conceptuellement, c'est la troisième solution qui est certainement la meilleure...
Pour l'instant, même si il n'y a que 2 langues, le jour où, si par mégarde, on te demande une troisième langue, alors tu seras heureux d'avoir fait ce choix.

Certes, la troisième solution nécessite une jointure supplémentaire, mais sur seulement 2 langues, ça ne devrait pas dégrader les performances énormément.

Et puis avec la première solution, ça fait quand même beaucoup de cases vides quand un ouvrage n'existe que dans une seule langue. C'est pas parce que l'octet ne coûte plus très cher qu'il faut gâcher . Et tout cet espace inutile ...

Bref, tu l'auras compris, je vote 3 .

ced

[redah75]

Pour l'instant, même si il n'y a que 2 langues, le jour où, si par mégarde, on te demande une troisième langue, alors tu seras heureux d'avoir fait ce choix.

c'est sur qu'il y aura JAMAIS une 3eme langue

et la 2e solution? sachant que titre_en et text_en sont TOUJOURS remplis!!

je profite de ce post pour te poser une autre petite question, hier un ami me demande un conseil, je lui ai donne une solution qui me parait bien mais je n'en suis pas sur
il fait un petite base de donnes pour des avions et vols effectues par des pilotes amateurs...
j'ai dit qu'il faut mettre une table pilotes, vols_effectues, avions, ...:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
pilotes:
id, nom, prenom, ...
 
vols_effectues:
id, id_pilote, id_avion, date_vol, ...
 
avions:
id, type, immatriculation, ...

et c'est la ou je me pose des questions, il peut y avoir plusieurs avions du meme type avec des immatriculations differentes. la solution que j'ai trouve est:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
avions:
id, id_type, ...
 
avions_immatriculation:
id_avion, immatriculation
 
types:
id, type

qu'en penses tu?

Merci