Requête de recherche [Résolu]

Signaler
Messages postés
8
Date d'inscription
lundi 5 avril 2004
Statut
Membre
Dernière intervention
31 juillet 2007
-
Messages postés
8
Date d'inscription
lundi 5 avril 2004
Statut
Membre
Dernière intervention
31 juillet 2007
-
Bonjour,

Voila, pour l'un de mes examens d'informatique, nous avons du concevoir sous Access, la base de données d'une vidéothèque.
J'ai organisé une Table "Films" avec les champs suivant :

IDFilm
Titre
Realisateur
Acteurs
Scenariste
Annee
Studio
Genre
GenreBis
DateSortie
Duree
Disponible
Support

J'ai placé le type du champ "Acteur" à 255 caractères (Texte) afin de pouvoir y placer le nom des différents acteurs les plus importants figurant dans chaque film.

A l'aide d'un formulaire indépendant, j'ai placé autant de filtre que de champs, c'est-à-dire que l'on pouvais, par exemple, rechercher le nom d'un acteur à travers la liste de film en se tablant sur le champ "Acteurs" de la table "Films".

Le but de l'examen étant ici de montrer l'utilisation de requêtes SQL, je n'ai donné la possibilité que de rechercher uniquement un acteur (en rechercher plusieurs aurait était facile, il fallais uniquement rajouter une zone de texte "ActeurBis" etc. comme je l'ai fait pour les genres du film.

Mon prof m'a alors dit que sur une base de donnée de plusieurs millier d'enregistrements (nous nous fixeront le nombre de 3000 enregistrements) la recherche serai lente de par le fait qu'il faille analyser le contenu d'un champ de 255 caractères pour chaque enregistrement pour retrouver celui ou ceux souhaité(s).

Il m'a donc proposé comme solution de créer une table "Acteur" comportant les noms de ceux ci (ainsi qu'un ID unique) et de créer une table qui servirai uniquement de relation entre les films et les acteurs en y placant les ID de ceux-ci en relation avec les ID des films dans lesquels ils ont joués.

Sur une base de données d'environs 3000 enregistrements, connaissant la puissance et la rapidité des requêtes SQL, la différences de temps n'est elle pas purement mathématique ? (Si toute fois il y a différence de temps)

Il ma aussi dit, que la base de donnée, serai plus grosse de par le fait de l'utilisation d'un champ de 255 caractères, d'un autre coté, mon champ de 255 caractères évite la création de 2 tables (la table qui met en relation les acteurs avec leur film ainsi que celle ou sont référencé tout les noms des acteurs avec leur ID)

Que pensez-vous de cette remarque ? Dans le cas d'une Vidéothéque, cela change-t-il vraiment quelque chose ? La base de donnée sera elle réelement plus grosse dans le cas de l'utilisation d'un champ de 255 caractères par rapport à 2 tables supplémentaires.

D'avance, merci pour vos réponse & Bonne prog a tous.

2 réponses

Messages postés
268
Date d'inscription
samedi 22 février 2003
Statut
Membre
Dernière intervention
24 avril 2013
3
Ben en fait oui et non
2 choses :

Tu as raison pour 3000 enregistrement c'est pas grand chose(encore que Access...).

MAIS imagine que t'as viéothéque est en ligne et que ca cartonne et que tu as 300 requette secondes(Bon faut vraiment que ca cartonne!!!).
MAIS imagine que t'as vidéothèque Grossisse A 100000 enregistrements...
MAIS imagine que ton client est supercontent de sa vidéothèque et qu'il veuille créer un affichage par auteur(la tu vas galéré sans table à par et sans être impossible, la sollution demandera des ressources disproportionnée par rapport au problème)

ENFIN La solution de ton prof est plus éléguante, les bases de donnée sont prévu pour faire du relationnel, c'est là qu'elles se différencie d'un fichier Excel et c'est comme cà qu'il faut s'en servir, on le voi la solution a trois table est beaucoup plus évolutive, elle permetrat au administrateur de vérifier plus facilement les Auteur en doublon, et en plus on pourrat rajouter queques champs dans la table auteur (Naissance,Mort,Biographie...). dans la création d'une base de donnée, il faut toujours pensée a l'évolution future de celle-ci (c'est capiutale quand ton client change d'avis Trois ou quatres fois avant d'être satisfait, ou veut faire évoluer son produit).

c'est souvent un peu chiant au départ mais on en voi vite le bénéfice quand on a affaire a des client qui ne définissent jamais un cahier des charge parfait des le premier jet(quand il en font un).
Messages postés
8
Date d'inscription
lundi 5 avril 2004
Statut
Membre
Dernière intervention
31 juillet 2007

Bonjour,

Merci pour votre réponse, effectivement, je me suis procuré diverses bases de données qui pourraient me servir d'exemple et on remarque que cette technique est très souvent utilisée.