Modélisation des artistes
Bonjour,
Je souhaite améliorer le modèle de ma base de données personnelle sur le cinéma et je me demande quelle est la meilleure manière de modéliser un artiste.
La notion d'artiste est à prendre au sens très large de toute personne participant à un film (acteurs, réalisateur, techniciens...)
Aujourd'hui, j'ai cette table :
t_e_personne_prs (per_id, per_nom_reel, per_prenom_reel, per_nom_public, per_prenom_public, per_sexe, per_date_naissance, per_date_deces, per_pays_id, per_commentaire)
Il y a pas mal de colonnes nullables dans cette table et c'est ça que je voudrais améliorer, convaincu par les arguments de fsmrel qui chasse le bonhomme NULL dans les vertes prairies du Relationland.
1) Commençons par le plus facile : les dates.
Je ne connais pas les dates de naissance de tous les artistes et encore moins leur date de décès puisque beaucoup sont encore en vie.
Il convient donc de sortir les dates de naissance et de décès de cette table qui sera très sollicitée par mon programme.
MCD :
personne -0,1----naître----0,n- date
|--------------0,1----décéder----0,n---|
Comme je vais gérer pas mal de dates, en plus de celles ci-dessus (date de sortie d'un film, date de parution d'une revue ou d'un livre, date de projection en festival, dates de début et de fin d'un festival...), je vais probablement être amené à créer un calendrier en BDD. Peut-être toutefois pas aussi complexe que celui de SQLPro, mais j'envisage de séparer les jours, mois et années car je peux n'avoir l'information que d'une date imprécise (Untel est né en 1902 et mort en 1990) ou n'avoir besoin que du mois et de l'année, par exemple pour un magazine mensuel.
Mon MCD simple ci-dessus ne devrait-il pas se complexifier en faisant 3 associations pour "naître" (vers jour, mois, année) et de même pour "décéder" ?
Bref, comment modéliser le fait que la date peut être incomplète ?
2) Plus compliqué peut-être : les noms.
Si j'ai, dans ma table actuelle, séparé les noms et prénoms réels et publics, c'est parce que certains artistes sont connus sous un pseudonyme. Détail qui complique encore la chose, certains pseudonymes sont composés d'un nom et d'un prénom (Marylin Monroe) et d'autres seulement d'un nom (Arletty, Miou-Miou).
Alors quoi mettre dans la table des personnes et quoi mettre dans une table séparée ?
Première solution : Sortir le nom réel.
Les artistes sont connus sous leur nom d'artiste, figurant au générique des films, que ce nom soit leur nom réel ou un pseudonyme.
MCD :
personne -0,1----avoir----(1,1)- nom_reel
Mais si je sépare le nom et le prénom dans les deux tables résultant de ces deux entités types, je peux de nouveau voir apparaître le bonhomme NULL, par exemple pour Miou-Miou qui n'a pas de prénom dans son nom d'artiste.
"Ben, t'as qu'à faire une seule colonne pour le nom d'artiste qui contiendra le nom et le prénom !
- Oui mais, quand je vais vouloir afficher une liste d'artistes, j'aimerais que Marilyn Monroe soit classée à Monroe et pas à Marylin !"
Il y aurait la solution d'écrire dans cette colonne unique "Monroe (Marylin)" et de reconstituer par programme le joli nom de "Marylin Monroe" lors de la présentation de la donnée, mais je trouve ça un peu moyen comme solution et pas très naturel à la saisie... bref, j'aime pas trop.
Deuxième solution : Sortir le pseudonyme.
Le nombre d'artiste ayant un pseudonyme est relativement faible. On pourrait alors suivre la majorité et externaliser les quelques fantaisistes qui ne sont pas assez fiers de leur patronyme ! :P
MCD :
personne -0,1----avoir----(1,1)- pseudonyme
Les problèmes soulevés précédemment sont là aussi présents (prénom optionnel) auquel s'ajoute le fait que je ne connais pas forcément le nom réel de certains artistes à pseudonyme, ce qui reviendrait à avoir des anonymes dans la table des personnes !
Voilà où j'en suis de ma réflexion. Espérant que vous aurez eu le courage de me lire jusqu'au bout, j'attends vos commentaires et suggestions.
de l'utilité des NULL... parfois.
Bonjour,
Citation:
Envoyé par
CinePhil
pour des besoins de recherche sur ces critères, il me semble que NULL rend les index beaucoup moins efficaces.
En quoi les index sont moins efficaces ?
Seules les entrées d'index non nulles sont indexées.
C'est plus optimal qu'une jointure avec une autre table car l'index fait directement le lien entre la valeur et l'enregistrement recherché alors que passer par une autre table fait le lien valeur -> ID (de cette autre table) puis on doit faire ensuite ID -> enregistrement recherché. Double de ressources. Double de temps.
Et si l'on veut indexer les NULL (pour faire une recherche de tous les nulls par exemple) , on peut le faire aussi. ce sera probablement toujours meilleur qu'un NOT EXISTS vers une autre table.
Au contraire, mettre une colonne indexée à NULL peut être un choix d'optimisation.
Un exemple: une table de commandes avec un flag qui dit si la commande est traitée ou non. La plupart des commandes sont traitées (pas besoin d'index là dessus donc vu la faible selectivité) et on doit par contre rechercher les quelques commandes qu'il reste à traiter.
Si on met un flag NOT NULL qui prends les valeurs 'Y' ou 'N' alors va être indexé même ce dont on a pas besoin. On a un gros index dont une grande partie est inutile. Alors que si on met NULL pour les commandes déjà traitées, on a un tout petit index qui n'indexe que ce qu'on veut et qui est très performant.
Citation:
Envoyé par
ok.Idriss
Enfin, une troisième solution qui n'a pas été envisagée c'est d'enregistrer les dates non pas avec une colonne de type DATE mais une colonne en VARCHAR avec un caractère de séparation et un caractère indiquant l'absence d'une donnée. Exemple : X-X-2011, 11-10-2010, X-01-2009, etc.
Très mauvais pour l'optimiseur qui ne connaît plus les données qu'il traite. Des problèmes de tris ou de comparaison de date. Impossible d'adapter le format de date si on a des utilisateurs internationaux.
Des solutions ? On pourrait mettre une date + une colonne de précision (jour, mois année). Ou bien 2 dates min et max. Quel que soit le choix, c'est facile de passer de l'un à l'autre avec les fonctions de dates du SGBD. Et on peut trier, comparer, afficher comme on veut,...
Ça me fait penser à un exemple d'application qui ne voulait pas utiliser des NULL: en anglais
L'appli permettait de saisir les numéros de plaques d'immatriculation pour envoyer la facture du parking. Lorsqu'une voiture n'avait pas de plaque, le gardien saisissait XXXXXXX.
Sauf qu'un jour quelqu'un a une une vraie plaque XXXXXXX ... et il a reçu une note de parking de 19000 dollars :D
Est-ce qu'il n'aurait pas mieux valu mettre un vrai NULL pour indiquer l'absence d'information ?
Cordialement,
Franck.