Exact sauf que je préfére photo_url ou photo_nom au lieu de photo_id si tu entends utiliser un numérique pour photo_id car le nom/url (de la source de la photo) doit être unique et peut être l'identifiant de la photo c'est plus économique pour les requêtes.
Je veux dire, quand par exemple tu ouvre la table tournoi_prefectures tu peux avoir directement l'url de l'image pour l'afficher au lieu de raccorder toujours la table photos en faisant un lien photo_id.

La table photos reste donc moins sollicitée mais son rôle peut être la centralisation des informations sur les photos partagées de la base.

(desole 2 posts pour le prix d'un mais mon message semble considere comme du spam...)

[quote]Le système de mise en valeur par défaut de l'url d'une même photo en cascade sur tous les noeuds d'une hierarchie logique de données est intélligent. Il peut être réalisé aisement par un traitement de mise à jour en cascade.

Voir la photo comme une entité partagée, permet de constituer un système de gestion de gallerie de photos et d'administrer la distribution et la mise en forme des photos.[/quote]

Evidemment ! Je voulais la mettre dans une entite separee mais je ne savais pas comment l'integree dans le schema, c'est pourtant simple :
[code]
photos
-photo_id
photo_description
photo_path
[/code]

C'est bien cela ?
winner_picture disparait de la table tournoi_winners remplace par photo_id et toutes les autres entites prennent pour cle etrangeres photo_id (categories, editions, prefectures, winners)
il serait ensuite possible de rajouter assez aisement une photo pour les prix ou chaque place, si le besoin venait a se faire sentir.
Si l'on choisit de mettre une photo pour une categorie et de la mettre en defaut, il faudrait cependant que seuls les tables editions, prefectures ne soient actualises.
il faudrait offrir de pouvoir mettre en defaut deux types a chaque niveau :
- categories/editions/prefectures (rajout de schedule au besoin)
- gagnants
et si besoin est,
- prix

Est-ce que cela semble coherent ? et etait-ce le principe dont tu parlais ?

En tout cas merci !

Merci encore pour ton aide!

[quote]Pourquoi faire ce long chemin en aval à la quête d'infos de l'édition alors qu'en amont, le parent de prefecture, l'édition elle même est au rendez-vous. Dans tournoi_prefectures il y'a edition_id qui mène directement à tournoi_editions là où l'année et le numéro se trouvent.[/quote]

Effectivement !
Au depart ma requete ne cherchait pas a retrouver les informations sur l edition mais juste les informations sur les gagnants et leur prix pour les afficher dans l ordre de disposition voulu.
Je suis parti donc de cette requete qui m amenait jusqu a l ordre des prix pour remonter vers les informations de l edition... mais evidemment, c etait une erreur !

J ai donc decide de faire deux requetes au lieu d'une :
une qui choisit le chemin que tu as indique pour retrouver les informations sur l'edition a partir de la prefecture et
une autre qui retrouve les gagnants.
cela m evite de faire trop de jointures dans une seule requete et [i]peut etre [/i]que le coup est globalement plus leger sur 2 requetes :
1 requete :
- prix du bonheur gagne par john doe dans le tournoi vivre ensemble edition 3, annee 2007 dans le rhones a lyon
- prix du sourire gagne par barby dans le tournoi vivre ensemble edition 3, annee 2007 dans le rhones a lyon
....
2 requetes :
1: - tournoi vivre ensemble edition 3, annee 2007 dans le rhones a lyon
2:
- prix du bonheur gagne par john doe
- prix du sourire gagne par barby

du cote script serveur, il me semble que cela est moins gourmand a gerer dans une loop et que le nombre d octets traversant le serveur est reduit mais bon faire deux requetes est peut etre encore plus gourmand ?

[quote="shiri_rules"]
Concernant l ajout d'une regle sur prize_id dans la table tournoi_winners, j en comprends la finalite mais je ne sais pas comment l appliquer dans les faits... Concretement, il y aura un back end qui permettra de gerer plus les petites modifications que les grands insertions de donnees en masse mais je peux offrir seulement la liste des prix concernant l edition choisie de sorte que seul les prix de l edition soit rentres.
[/quote]
Effectivement, cette régle est une contrainte de validité de champ lié qui doit être surveillée par un trigger qui représente le système relationnel ternaire entre gagnant, prix et tournoi (édition)

[quote="shiri_rules"]
J'ai cepedant fait une belle faute de raisonnement (entres autres de mes multiples et constantes erreurs de raisonnements) :
je partais de tournoi_prefectures.prefecture_id puis retrouve le tournoi_schedules.schedule_id qui me permettait de retrouver tous les gagants d'une prefecture (independamment de la place) par rapport a une edition particuliere mais la ou je me suis trompe c est que je suis en suite parti de tournoi_winners.prize_id pour remonter vers tournoi_editions pour retrouver l annee et le numero de l edition...
mais voila, si j ai rentre les prefectures d une edition, les places et schedules pour cette prefecture mais pas les gagnants, je ne peux pas retrouver l annee de cette edition...
[/quote]
Pourquoi faire ce long chemin en aval à la quête d'infos de l'édition alors qu'en amont, le parent de prefecture, l'édition elle même est au rendez-vous. Dans tournoi_prefectures il y'a edition_id qui mène directement à tournoi_editions là où l'année et le numéro se trouvent.

[quote="shiri_rules"]
En tout cas dans ce schema, il me reste encore inserer les photos... et la,,,

il peut y avoir une photo pour une categorie
une photo par defaut pour une edition
une photo pour une prefecture
une photo pour les gagnants (no picture).

je voulais que si l on chosit une photo pour une categorie, on puisse la mettre en defaut pour toutes les editions qui en dependent.
si on met une photo par defaut pour une edition, on puisse la mettre en defaut pour toutes les prefectures...

et du coup, je pense que je vais faire plus simple et arreter le concept de photo par default^^;[/quote]
La photo peut être vue comme une information partagée, le nom de sa source est un caractère physique d'unicité, l'url (même avec un chemin relatif) peut jouer le rôle d'identifiant unique, et migrera là où une représentation de la photo est nécessaire.

Le mécanisme de représentation des photos par leurs urls présente une simplicité de développement et une économie de l'espace de stockage de la base car les photos sont stockées sur le système de fichiers hors base et peuvent être manier par des outils spécifiques.

Le mécanisme de partage logique implémente implicitement un partage physique des ressources car si une même photo concerne plusieurs occurences de données dans la base, le partage de son url permet de ne stocker effectivement la photo qu'une seule fois.

Le système de mise en valeur par défaut de l'url d'une même photo en cascade sur tous les noeuds d'une hierarchie logique de données est intélligent. Il peut être réalisé aisement par un traitement de mise à jour en cascade.

Voir la photo comme une entité partagée, permet de constituer un système de gestion de gallerie de photos et d'administrer la distribution et la mise en forme des photos.

Merci beaucoup pour ton aide et la vue que tu apportes sur le modele ! (et desole pour cette reponse tardive...)

La lecture du modele faite, designe exactement le cas concret modelise !

Concernant l ajout d'une regle sur prize_id dans la table tournoi_winners, j en comprends la finalite mais je ne sais pas comment l appliquer dans les faits... Concretement, il y aura un back end qui permettra de gerer plus les petites modifications que les grands insertions de donnees en masse mais je peux offrir seulement la liste des prix concernant l edition choisie de sorte que seul les prix de l edition soit rentres.

J'ai cepedant fait une belle faute de raisonnement (entres autres de mes multiples et constantes erreurs de raisonnements) :
je partais de tournoi_prefectures.prefecture_id puis retrouve le tournoi_schedules.schedule_id qui me permettait de retrouver tous les gagants d'une prefecture (independamment de la place) par rapport a une edition particuliere mais la ou je me suis trompe c est que je suis en suite parti de tournoi_winners.prize_id pour remonter vers tournoi_editions pour retrouver l annee et le numero de l edition...
mais voila, si j ai rentre les prefectures d une edition, les places et schedules pour cette prefecture mais pas les gagnants, je ne peux pas retrouver l annee de cette edition...

c est pourquoi je me demande si cette enchainement de cles qui 'heritent' des informations les unes apres les autres est une bonne methode...

En tout cas dans ce schema, il me reste encore inserer les photos... et la,,,

il peut y avoir une photo pour une categorie
une photo par defaut pour une edition
une photo pour une prefecture
une photo pour les gagnants (no picture).

je voulais que si l on chosit une photo pour une categorie, on puisse la mettre en defaut pour toutes les editions qui en dependent.
si on met une photo par defaut pour une edition, on puisse la mettre en defaut pour toutes les prefectures...

et du coup, je pense que je vais faire plus simple et arreter le concept de photo par default^^;

Voici ma lecture de ton modèle, ça peut aider:
[list]une catégorie de tournoi peut apparaitre dans plusieurs éditions.

Une édition correspond à une seule catégorie de tournoi.

Une édition peut avoir plusieurs prix et un prix correspond à une seule édition.

Une édition de tournoi concerne plusieurs préféctures mais une préfécture n'est responsable que sur une seule édition.

Une préfécture réserve des places et des dates pour l'édition dont elle est résponsable.

Un tournoi planifié par une préfécture/édition peut avoir plusieurs gagnants et prix

Un gagnant gagne un tournoi planifié par une préfécture/édition et un prix

Un prix/édition peut être attribué à plusieurs gagants quelque soit le tournoi
[/list]
La lecture logique devient de plus en plus difficile en ce qui concerne la réglementation des relations bijectives entre le gagant, le tournoi qu'il gagne et le prix de l'édition.

je pense qu'il faut ajouter une règle qui limite un id_prize de la table tournoi_winners à seulement les prix de l'édition dans laquelle il a gagné. Car en connaissant un winner par son [b]tournoi_winners.winner_id[/b] on connait alors le [b]tournoi_winners.schedule_id[/b] qui fait connaitre le[b] tournoi_schedules.prefecture_id[/b] qui fait connaitre le [b]tournoi_prefectures.edition_id[/b] qui finalement fait connaitre les différents prix de l'édition [b]edition_prizes.edition_id[/b]
Cette règle est manquante dans le modèle et donc on peut trés bien enregistrer un gagnant dans un tournoi avec un prix qui ne correspond pas à l'édtion du tournoi.

Bonjour!

J ai realise un schema relationnel mais lorsque je regarde le schema, il me semble etrange...

Je dois realiser une base pour des tournois dont voila le schema que j ai structure :
[code]
| tournoi_categories|

- category_id
category_name
category_description
|
1,n
|
|tournoi_editions| -- 1,n -- |edition_prizes|

- edition_id -prize_id
#category_id #edition_id
edition_year prize_name
edition_name display_order
edition_number
edition_description
|
1,n
|
|tournoi_prefectures|

- prefecture_id
#edition_id
prefecture_name
|
1,n
|
|tournoi_schedules|

-schedule_id
#prefecture_id
place
tournoi_date
|
1,n
|
|tournoi_winners|
-winner_id
#shedule_id
#prize_id
winner_name
winner_picture[/code]

on peut obtenir la page suivante :

- id 1 : tournoi 'vivons ensemble'
- edition_id 1> category : 1 ediition 2005 (7eme edition)
- prefecture_id 5 > edition_id 1 Rhones-alpes
- place 8 > prefecture_id 5 Lyon
- prize_id 2> place_id 8 Prix du coeur
- john doe
- Prix du meilleur sourire
- barbye


Ce que je trouve bizarre dans ce schema, c'est que tout est lie par des cles etrangeres 'descendantes' et je ne suis pas sur d avoir place tout au bon endroit...
On pourrait representer cette structure comme un arbre et donc peut etre que passer a un modele 'nested' serait meilleur mais les donnees recues par lot sont sous format excel et convertir ca dans ce schema me semble etre trop long...

Voyez-vous une erreur de conception ? une facon de faire differente ?