[conception] champs vides ou plusieurs tables ?

Voilà,

je désirerais stocker des données relatives à un stock de documents.

Il y a 4 types de doc (livres, revues, rapports et administratif). Ces 4 types ont en commun les 2/3 des données. Je veux dire par là, que pour chaque type il y a un titre, un editeur, une année de parution ... (une dizaine)
Je n'ai ensuite que quelques champs supplémentaires pour chaque type. Pour livre par exemple je rajoute reference, nb pages, isbn.

Du coup, je ne sais pas quelle solution adopter.
1) Une seule table document avec tous les champs supplémentaires des types. peut etre trop lourd à faire évoluer...
2) gérer une table document et 4 tables pour les infos supplémentaires. Les lier par clés, référence ?

Enfin voilà, je souhaiterais avoir vos avis et expérience sur ce type de conception. Tous documents confondus la base devrait atteindre 5000 exemplaires, grand maximum ...

aller, merci d'avance ...

Choix 2) pour la lisibilite et la maintenance

solution 2

Merci beaucoup. je pensais effectivement faire comme ça mais aujourd'hui je suis plein de doute :?

Juste une dernière petite question ...

Je vais surement utiliser PostgreSQL. Je ne sais pas s'il permet d'utiliser les references ou de l'héritage ...
Mais au sujets des liens (1-1) entre les tables, vo t'il mieux :
1) un lien du livre vers le document
2) l'inverse
3) un double référençage
4) Utiliser autre chose que des clés étrangères

2) Un lien du livre, etc... vers le document
et l'indication du type de document dans le document.

En clair (!)

Table Document
Id_Document, Clé Primaire
Type_Document, Obligatoire
Autres_Attributs...

Table Livre, Rapport, ...
Id_Document, Clé Primaire ET Clé Etrangère sur Document
Autres_Attributs...

Ok merci beaucoup. je pensais bien à l'attribut type de doc, mais je pensais que peut etre y'aurait eu une solution plus "propre", enfin je sais pas.

Donc c cool. J'implenterais ça plus tard. Merci à tous encore une fois

Tu peux aussi effectuer des jointures externes entre la table Document et les tables Particulières si tu le préfères, mais ce sera certainement plus lourd à gérer au niveau de la base de données et de l'IHM.
Là, on entre dans le débat sur "la dénormalisation lors de l'implémentation" :roll:

Ton modèle correspond à un héritage à exclusion mutuelle.

Lire à ce sujet :
http://sqlpro.developpez.com/heritage/herit.html

A +