Discussion :

[blondelle]

Bonsoir:
Apres avoir fait des essais avec ADO, je prepare un projet de base de donnees, j'en suis a la formalisation sur papier afin de percevoir les besoins, cette base est prevue avec deux tables.
Il me reste un probleme je ne vois pas comment assurer le lien entre ces deux tables.
Le projet se compose d'une table auteur d'une table livres.
Par exemple si j'appel un auteur je sort le descriptif de cet auteur mais si je le desire je sort les livres qu'il a ecrit, c'est la liaison entre l'auteur et les livres qui me pose probleme je ne vois pas comment faire ce lien.

[Sunchaser]

Bonsoir Blondelle,

Quels sont les champs prévus dans la table 'Livre' ?
Dans cette table, n'y a t il pas tout simplement moyen de faire une référence a l'auteur ? (pour chaque tuple ...) sur laquelle on pourrait filtrer ou 'requêter' ?

@ +

[blondelle]

Merci pour ta reponse Sunchaser:
Les tables auteurs livres c'est pour l'exemple, la table livres va avoir une trentaine de champs, la table auteur est la table principale et c'est a partir de celle ci que je vais si besoin aller chercher les livres correspondant a l'auteur, ce nombre de livres ne sera pas constant, suivant l'auteur il y en aurra un nombre different mais je voudrais tous les lister.

[Sunchaser]

De mon côté, ce que j'aurais fait (mais qui peut être considéré comme 'basique' voire obsolète par de vrais spécialiste des BD) est de garder une référence (donc un champs) a l'auteur pour chaque livre de la table 'Livres'.
Ainsi, lors d'une sélection d'un auteur dans la table principale, je filtre la table 'Livres' en me servant de la valeur représentée par l'auteur.
J'aurais utilisé un des évènements de TTable ou de TDataSet représentant la table principale, ou des composants correspondants a ce que tu utilises dans ton cas, pour automatiser le 'phénomène'.
Ou dans le cas d'Interbase, utilisé un 'Trigger' directement dans la BD ou qqchose dans cet de cet ordre en tout cas ...

[blondelle]

Je vais utiliser une base Access avec ADO.
Si j'ai bien compris tu te reserve un champ pour l'auteur dans la table livre.

[Sunchaser]

Ben voui ... c'est peut être pas très fineau mais c'est ainsi que j'aurais fait.
Et j'aurais surement testé avec un des évènements de TAdoDataset, comme AfterScroll, pour lancer le filtre (ou la requête) sur la table Livre.

En espérant t'aider,
@ +

//EDIT : mais je suis peut être dans l'erreur ...

[Interruption13h]

Merci pour ta reponse Sunchaser:
Les tables auteurs livres c'est pour l'exemple, la table livres va avoir une trentaine de champs, la table auteur est la table principale et c'est a partir de celle ci que je vais si besoin aller chercher les livres correspondant a l'auteur, ce nombre de livres ne sera pas constant, suivant l'auteur il y en aurra un nombre different mais je voudrais tous les lister.

Salut !
Je suis de même avis, sauf que je n'utiliserai pas le type auto-incremetal, puisque j'avais des problèmes lors de l'insertion des tuplets en utilisant des requête SQL, j'avais un message dans le genre : "Auto-Incremenatle type is not supported on SQL"; Je sais pas si c'est spécifique à PARADOX, peut être qu'il n y a pas de ce genre de problème dans ACCESS.

C'est juste une remarque, ensuite ta table LIVRE va avoir 30aine champs, elle doit sûrement être réduite, et dévisée en plusieur tables de façon mieux structuré, et ceci te permetra d'avoir un accés à tes données plus rapide, et moins gourmant.


Espérant t'aider !

Bonne chance.

[say]

Bonjour,
je me permets de mettre mon grain de sel...
En effet, je suis surpris de voir nul part la notion de clé primaire et clé étrangère..c'est pourtant exactement le principe ici.

Je ne vois pas en quoi ce serait obsolète,c'est la base des bases de données.
ici, l'IDAuteur (automatique ou pas) est la clé primaire de la table Auteur, garantissant l'unicité de chaque enregistrement (il est tjrs possible de créer des clefs alternatives par le biais de contrainte, ex : nom / prénom).
On reprendra donc cet IDAuteur dans la table Livres sous forme de clé étrangère, garantissant ainsi l'intégrité référentielle, comme le souligne FBartolo). C'est-à-dire que l'on ne pourra avoir d'IDAuteur dans LIvres qui n'est pas de correspondance dans Auteurs. Cela fait parti des mécanismes classiques des SGBDR.

Cependant, ce choix suppose qu'il n'y ait qu'un auteur par livre.
Il conviendra d'ajouter une table d'association entre les deux table si l'on souhaite traiter plusieurs auteurs par livre.

en espérant aider

[say]

C'est juste une remarque, ensuite ta table LIVRE va avoir 30aine champs, elle doit sûrement être réduite, et dévisée en plusieur tables de façon mieux structuré, et ceci te permetra d'avoir un accés à tes données plus rapide, et moins gourmant.
.

Honnétement, 30 champs c pas grand chose...on ne découpe que si cela a lieu d'être. Cette pratique me semble avoir disparu avec l'apparition de capacités de traitement bien meilleures.

[Interruption13h]

Honnétement, 30 champs c pas grand chose...on ne découpe que si cela a lieu d'être. Cette pratique me semble avoir disparu avec l'apparition de capacités de traitement bien meilleures.

Oui c'est sûre, mais ce que je veux dire ce que je me demande bien quel sont ces champs, puisque je voi qu'une dixaine de champs : Reference,Titre,Id_Auteur,Id_Catégorie... mais 30 !!?

Et c'est pas parceque la capacité de traitement a été améliorée qu'on doit forcément changer cette pratique

A+