Allgemeine Frage bgl. Tabellen-Struktur

Hallo zusammen!

Steh grad vor nem konzeptionellen Problem. Folgende Situation (umgeschrieben für besseres Verständis):

Angenommen ich habe im meinem Programm verschiedene Fahrzeug-Klassen (PKW, LKW) die allesamt von 'Fahrzeug' (Klasse ist abstrakt, kann also alleine nicht existieren) abgeleitet sind.
Fahrzeuge hat bestimmte Eigenschaften, PKW und LKW haben zusätzlich zu den geerbten Eigenschaften auch noch jeweils andere Eigenschaften (unterschiedliche natürlich).

Nun möchte ich die Fahrzeuge in eine Datenbank speichern. Mir sind 2 Möglichkeiten eingefallen wie die DB-Struktur aussehen könnte:

Möglichkeit A:
Grundinformationen von Fahrzeug in eine eigene Tabelle schreiben:
FAHRZEUG: FahrzeugID, AnzahlRäder
PKW: PKWID, FahrzeugID (FK), AnzahlTüren, Kofferraumvolumen
LKW: LKWID, FahrzeugID (FK), MaxLadegewicht

Beim Abspeichern speichert die Fahrzeug-Klasse die Grunddaten und die abgeleiteten Klassen nur die zusätzlichen Eigenschaften.

Vorteil:
Ich brauche nicht vor jede abgeleitete Klasse die Grunddaten speichern, sondern kann mich darauf konzentrieren die neuen Eigenschaften zu speichern.

Nachteil:
Informationen sind zerstreut und, falls ich mich richtig errinnere, die Tabellenstruktur ist nicht normalisiert.

Möglichkeit B:
Die Grundunformationen in die einzelnen Tabellen übernehmen:
PKW: PKWID, FahrzeugID (FK), AnzahlTüren, Kofferraumvolumen, AnzahlRäder
LKW: LKWID, FahrzeugID (FK), MaxLadegewicht, AnzahlRäder

Vorteil:
Informationen sind nicht zerstreut. Insert/Update/Select usw. performater.

Nachteil:
Bei einer Suche nach z.B. Frahzeugen mit x Rädern muss ich alle Tabellen durchsuchen und ich muss mich bei jeden Sub-Klasse wiederholt um die Grunddaten kümmern.

Noch einige Informationen zum Programm:
Es wird 20 bis 30 Sub-Klassen geben und einige tausend Datensätze/Sub-Klasse .Es handelt sich um eine Verwaltung von benutzer-definierten Eigenschaften einer Kontakt-Verwaltung. Also der Benutzer kann z.B. zu einem Kontakt eine zusätzliche Adresse anhängen usw.

Welche Möglichkeit würdet ihr nun empfehlen? Welche wendet ihr selbst an? Und aus welchen Gründen?
Oder gibt es gar eine andere Möglichkeit?

Vielen Dank schonmal für die Antworten!

BTW: Ist es schlecht, wenn eine Tabelle 3 oder 4 PrimaryKeys hat?

Mit freundlichen Grüßen,
DeveloperX

Hierfür gibt es evtl. eine schöne und einfache Lösung, da die Möglichkeit B einfach nur abgrundtief böse ist. Man muss nämlich immer vermeiden, Daten mehrfach in der Datenbank abzulegen. Daher bietet sich eine objektrelationale Datenbank an. Eine solche ist beispielsweise die Postgresql-Datenbank. Ich habe hier sogar einen Link für dich, der dir vielleicht weiterhilft:
http://www.postgresql.org/docs/8.1/interactive/sql-createtable.html
Stichwort INHERITS

Variante A ist der Klassiker und wird so auch von allen O/R-Mappern (die ich kenne) umgesetzt.

Die Variante B ist zu fehleranfällig weil es zu leicht möglich ist aus Versehen die Basisklasse zu umgehen.

Ich würde allerdings auf LKWId etc. verzichten. Eigentlich reicht die FahrzeugID als PK in allen Tabellen, es sei denn du willst eine extra Identifizierung haben. Hängt aber alles auch davon ab, wie deine Anfrage aussieht: Angenommen du willst Fahrzeug X holen und dann rausfinden um welchen Typ Fahrzeug es sich handelt. Bei sowas kommst du nicht umhin den Typ (bzw. den Tabellennamen für die Subklasseninformationen) selbst in der Basisklassentabelle zu speichern.

Das beantwortet auch deine Frage: Wenn du mehrere PKs hast, müssen entsprechend viele Indexe geführt werden. Kostet Platz in der DB und Zeit beim Einfügen eines Datensatzes.

Kleiner Tipp: Es gibt diverse Artikel im Netz, die sich mit der Funktionweise von O/R-Mapping beschäftigen. Da werden die Vort- und Nachteile ausführlich diskutiert. Danach würde ich mal suchen.

Vielen Dank an euch Beide!

Ich werd mir mal zu den von euch genannten Themen Informationen suchen!

mfg