Filmdatenbank mit verschieden benutzern(listen)

Ist mit der Aufteilung in drei Tabellen alles möglich!
Für jedes Attribut (Genre etc.), was man eingeben können soll, machst Du eine Spalte in der Filmtabelle.
Und lies Dir die Posts bitte auch durch!
Code: 
Mit SELECT * FROM Filme;
erhältst Du dann alle diese Daten und kannst dem User anbieten, mit einem Link, diesen Film zu übernehmen. Dann schreibst Du
Code: 
INSERT INTO Filmbesitzer (UserID,FilmID) VALUES ('$userID','$filmID');
$userID und $filmID solltest Du mit dem Link übergeben.
Alle Angaben bezogen, auf die Tabellenstruktur, die ich oben als Beispiel gewählt habe,

Wenn Du das mit der Normalisierung durchgearbeitet hast, sollte Dir auch auffallen, dass Du für die Genres auch eine eigene Tabelle machen solltest und wenn, wie oft üblich ein Film auch bei zwei Genres gelistet sein kann, auch dafür eine Tabelle, entsprechend der Filmbesitzertabelle.

Normalisierte Datenbanken wirken manchmal etwas unübersichtlich (für Einsteiger),
sind langfristig aber das (einzige) Mittel eine Datenbank konsistent, erweiterbar und vor allem redundanzfrei zu halten.

Gruß hpvw
 
Sorry!
Ich hatte aber meinen Beitrag oben aber schon geändert wei ich leider zu lange gebraucht hab zum schreiben.
Habet ihr wohl nicht bemerkt...naja egal

Also nochmal...Bin grad dabei mir den Eintrag im Wikipedia durchzulesen und meld mich dann nochmal wenn ich Probleme habe.
Auf jeden Fall dankeschön für eure vielen und vor Allem sehr schnellen Antworten!

bis denn
 
@redlama
Hatten wir so eine ähnliche Diskussion nicht schonmal?

Zur FilmID:
Ein Film ist nicht eindeutig durch seinen Titel gekennzeichnet. Daher kann dieser nicht als Primärschlüssel herhalten. Es gibt in der Realität (und daran sollte man sich orientieren) Filme mit gleichem Titel und unterschiedlichem Inhalt, z.B. Neuverfilmungen oder einfach bei der Titelwahl nicht aufgepasst, dass so ein Film schon vor 30 Jahren mal im Kino war. Hollywood denkt halt nicht an relationale Datenbanken.

Das man eine eigene Tabelle für die Filme braucht, darüber sind wir uns sicher einig.

Zur Usertabelle:
Ein Username sollte IMHO kein dauerhafter eindeutiger Schlüssel sein. Daher ist der User mit einer ID zu identifizieren und somit auch eine eigene Usertabelle anzulegen. Ich hatte es in eigenen Foren mit ähnlich privatem Nutzerkreis schon öfter, dass ein User nach einigen Jahren statt xy gerne xyz heißen würde, das ist dann ganz easy in der Usertabelle zu ändern und alles bleibt beim alten, bis auf den Namen. Außerdem gibt es unter Umständen noch andere Eigenschaften, zum Beispiel Rechte, die in der Usertabelle mit gespeichert werden. Irgendwann wird die Datenbank zum Beispiel auf Musik CDs erweitert und da stehen dann auch Usernamen drin, alles sehr doppelt, ein Indiz, für die Verletzung der 2. Normalform.

Die Verknüpfungstabelle benötigst du zwingend, um der ersten Normalform zu genügen, da es sich um eine m zu n Beziehung handelt.

Gruß hpvw

EDIT und schon wieder habe ich einen Beitrag verpasst.
 
redlama hat gesagt.:
@Sicaine und hpvw: Wieso sollte man 3 Tabellen anlegen, obwohl man nur 2 Felder bräuchte? Und warum eine ID anlegen?
Das erklärt mir mal bitte, ...!

redlama
Zum Vergrößern anklicken....

Tatsache ist, dass das was hpvw nich nur Standard ist! sondern auch nich umsonst so die normale Regel ist. Du kannst gerne deine Methode verwenden aber zur 3ten Normalform kommste damit nich und die is eben Standard für ne gute db-struktur.
Parallel dazu öhm was is wenn User Sicaine mit den Filmen Matrix, Herr der Ringe 1, Bad Boys2..... sich aufeinmal Überlegt öhm seinen Namen in Woiperdinger zu wechseln? Da siehste mehr als dumm aus der Wäsche wenn du xig Datensätze ändern musst. Weil sich bei dir Redudanz "eingeschlichen" hat, die vermieden werden soll wegen Update Lösch etc. problemen.
 
Nicht wenn man den Primärschlüssel über beide Felder setzen würde.
Da wäre ein Update des Namens nicht wirklich kritisch, ...

redlama
 
@redlama
Das war hier:
Thread von damals
Und Du hattest nur recht, weil ich die Frage nicht gerafft habe :-)
Am Ende hat sich dann aber doch herausgestellt, das die Anforderungen steigen und dann wäre es meine Lösung gewesen, so wie ich die Frage halt auch zuerst verstanden hatte.
Wer lesen kann ist klar im Vorteil und das warst in dem Fall Du.

Hier sehe ich aber keinen Weg, wie man sinnvoll mit weniger als 3 Tabellen auskommt. Auch wenn man Usernamenänderungen verbietet halt ich es für unpraktisch, wenn man für den User keine eigene Tabelle anlegt, auch wenn es prinzipiell möglich wäre. Ob es ohne Usertabelle normal ist, mag ich jetzt nicht beurteilen. Meine Devise ist jedenfalls: "Im Zweifel eine Tabelle mehr, als eine Tabelle weniger."

Gruß hpvw
 
Zuletzt bearbeitet:
redlama hat gesagt.:
Nicht wenn man den Primärschlüssel über beide Felder setzen würde.
Da wäre ein Update des Namens nicht wirklich kritisch, ...

redlama
Zum Vergrößern anklicken....

Hier gehts nich darum obs "kritisch" oder nich kritisch is und obs funktioniert oder nich.
Hier gehts darum dass das eine schlechte db-Struktur ist, die man einem Anfänger nicht beibringen soll und auch selbst nicht anwenden soll.
Kann schon sein, dass es vielleicht mal ein query mehr is aber dafür hast du halt 1. ne Redundantfreie, logische und gute DB-Struktur in der min. 3ten Normalform.

Und wie ich schon sagte 3te MINDESTENS!
Nebenbei: Ich lagere selbst land aus und speichere nich bei jedem User einzeln Deutschland, Schweiz...
 
redlama hat gesagt.:
Nicht wenn man den Primärschlüssel über beide Felder setzen würde.
Da wäre ein Update des Namens nicht wirklich kritisch, ...

redlama
Zum Vergrößern anklicken....
Das Update wäre genauso Kritisch, da Du ihn in jeder Zelle, in der er als Teil des Primärschlüssels auftaucht ändern müßtest, statt einmal in der Usertabelle.
Wenn Du wie als Beispiel angesprochen irgendwann noch mehr Tabellen hast, in denen der User auftaucht, wird es bestimmt irgendwo vergessen.
Deine Lösung mag für kleine Datenbanken gerade noch gehen, aber wenn die DBs größer und umfangreicher und komplexer werden ist das keine sinnvolle Praxis mehr. Und lernen sollte man es besser gleich richtig und von der Picke auf "richtige" Datenbanken entwickeln.
Als Beispiel ist bei mir eine Adressdatenbank durch die Normalisierung von einer Tabelle auf ca. 16 Tabellen angewachsen (tja, wenn man erstmal Gruppenzugehörigkeit eintragen will und mehrere Adressen pro Kontakt zulässt...).

Gruß hpvw
 
Um antworten zu können musst du eingeloggt sein.

Neue Beiträge

Zurück