Modellierung meiner Datenbank

[Sophus]

Hi Sophus
Ein GUID ist ein String. In MySQL würde wohl ein Longtext passend sein - nur würde ich sowas nie als ID verwenden. Ein Index sollte aus Performancegründen immer ein Integer sein.

Hey Delbor, es freut mich, dass du dich einbringen willst. Sollte ich für die GUID den Datentyp LONGTEXT benutzen, so wird die Suche ab einer bestimmten Menge an Datensätzen wesentlich länger dauern, richtig? Also, in der Datenbank Microsoft Access (welches mein Programm ebenfalls unterstützen wird) hätte ich wenig Probleme mit dem Datentyp, denn dort würde ich für mein Vorhaben einfach den Datentyp Replikations-ID verwenden. Im Internet sind sich einige nicht einig. Andere sagen der Datentyp VARCHAR (32), CHAR (32) oder BINARY (16) sei angemessen. Wobei ich mich frage, wieso bei BINARY die 16 genommen wird? Eigentlich ist eine GUID immer 36 Zeichen lang, jedoch werden die Sonderzeichen (in dem Fall die Bindestriche) von meinem Programm entfernt und die Kombination Zahlen/Buchstaben gespeichert. Und da ich absolut keine Ahnung habe welcher Datentyp wirklich angemessen ist, bin ich wirklich auf eine sichere Meinung angewiesen.

Ich habe mir dein Datenmodell nur ganz zu Anfang des Threads angesehen.

Wir sind schon ein kleines Bisschen weiter. Vielleicht fällt dir ja auch was auf das aktuelle Datenmodell was ein? Ich freue mich über jede Hilfe, die ich kriegen kann.

Belege das Feld mit einem Datumswert und erlaube, dass es auch NULL sein kann. Wenn da ein Datum drin steht, lebt die Person nicht mehr. Das Feld solltest du dann eventuell 'Sterbedatum' nennen, oder, Falls du schon ein solches hast, ganz weglassen.

Meines Wissens kennt MySQL keinen boolschen Datentyp - allerdings gründet diese Aussage auf Versuche meinerseits, die etwas länger zurückliegen.

Gruss
Delbor

Was mich an dieser Idee stört ist, dass man hierbei ein Prüfverfahren von Seiten des Programms einbauen musst. Das heißt, es muss geschaut werden, ob der Eintrag in dem Feld dem Format eines Datums entspricht. Und da sich europäische und amerikanische Formate gänzlich unterscheiden, müsste man erst einmal auf beide Formate hin überprüfen, ehe man feststellen kann, ob es sich um ein Datum handelt oder nicht. Und wenn ja, dann ist die Person tot. Ich habe gehofft, dass ich um solch ein Verfahren drumherum komme. Da ist das Arbeiten mit TRUE/FALSE wesentlich einfacher und am Ende effektiver.

Gruß
Sophus

 

[akretschmer]

Hi Sophus


Ein GUID ist ein String. In MySQL würde wohl ein Longtext passend sein - nur würde ich sowas nie als ID verwenden. Ein Index sollte aus Performancegründen immer ein Integer sein.

Depends. Es gibt Anwendungen, wo ein UUID Mittel der Wahl ist. Wenn z.B. auf N Seiten konflikfrei Keys zu erzeugen sind. Multi-Master-Datenbank-Geschichten zum Beispiel. Und die müssen auch nicht langsammer sein als 'normale' Indexe.

Meines Wissens kennt MySQL keinen boolschen Datentyp - allerdings gründet diese Aussage auf Versuche meinerseits, die etwas länger zurückliegen.

Korrekt. Ich kann Dir noch locker ein Dutzend weiterer Datentypen nennen, die MySQL nicht kennt.

 

[Sophus]

Bitte nicht abschweifen und meinen Beitrag "kapern" Für derartige Diskussionen, die nichts mit meiner Modellierung zutun haben können gern ausgelagert werden, ansonsten wird dies zu unübersichtlich, und keiner weißt am Ende worum es hier wirklich geht.

 

[Delbor]

Hi Sophus

Was mich an dieser Idee stört ist, dass man hierbei ein Prüfverfahren von Seiten des Programms einbauen musst. Das heißt, es muss geschaut werden, ob der Eintrag in dem Feld dem Format eines Datums entspricht

Um ein Feld einer DB-Afrage abzufragen, verwende ich:

if not isEmpty

Allerdings - ich arbeite mit Delphi (ObjectPascal). Ob es dass auch in andern Sprachen gibt, ist mir nicht bekannt, aber ich kann mir gut vorstellen, dass C#, C++, VBA und auch sowas wie PHP sowas kennen (IsEmpty := belegt, nicht leer).
Der DatumsTyp kann in der DB immer derselbe sein - das Programm soll den Datentyp in das Länderformat konvertieren, unter dem dein Programm läuft.

Gruss
Delbor

PS: Ganz abgesehen davon: du kannst deinem Feld gestatten, auch NULL zu sein. Der Defaultwert wäre dann 1, der Datentyp integer, und im Programm müsstest du sicherstellen, dass nur zB. '1' eingegeben werden kann. Weiter mussst du sicherstellen, dass niemand ohne dein Programm eine Verbindung zum Server einrichten und an diesem Feld hereumspielen kann. Und das ist nur dann möglich, wenn dein Programm den Server startet und beendet und ansonsten niemand zugriff auf den Server hat.

 

[Sophus]

Entscheidung (Wahl der Qual): So, ich habe mich (hoffe ich zumindest) entschieden. Ich stand zwischen den beiden Datentypen: VARBINARY (16) oder CHAR (32). Letztendlich habe ich mich für CHAR (32) entschieden. Warum? Nun ja, die GUID wird ja vom Client (meinem Programm) aus erzeugt und die Bindestriche werden ebenso vom Client (mein Programm) aus entfernt. Demzufolge erachtete ich es als unnötig die vom Client aus erzeugte und bearbeitete GUID als String bzw. binär abzuspeichern. Ich hoffe, dass durch meine Entscheidung keine bösartigen Überraschungen auf mich lauern - zum Beispiel Performanceverluste bei JOINS-Abfragen bzw. bei der Suche.

Hier meine überarbeitetes Datenmodell.

(Zum Vergrößern bitte auf das Bild klicken)

Änderungshinweise: Zunächst einmal habe ich die Tabellen farblich gekennzeichnet. Dies soll es leichter machen zu erkennen, welche Tabelle mit wem in Beziehung steht. Die Zwischentabellen bleiben immer schwarz, da solche Tabellen eher die »neutrale« Position einnehmen. Auf Anraten von Delbor habe ich in der Tabelle Person das Feld Status gelöscht, und das Feld StatusZeit in Todesdatum umbenannt. Des Weiteren habe ich auf Anraten von Distrilec die Tabelle GesamtBewertung gelöscht, und in der Tabelle FilmAllgemein ein Feld GesamtBewertung hinzugefügt.
--------------------------------------------

Aktuell: Hinzugekommen sind vier neue Tabellen: FilmDetail, FilmFassung,FSK und FilmZitat. Dazu kommt noch eine Zwischentabelle hinzu: FilmDetail_FilmFassung_FilmZitat.

Tabellen:
FilmDetail: Im Gegesatz zu der Tabelle FilmAllgemein werden hier detaillierte Informationen zu einem Film gespeichert.

FilmFassung: Denken wir mal an einen Horrorfilm. Es gibt den Horrorfilm als Kinofassung, als Red Edition, als Uncut Edition, als TV-Fassung etc.

FilmZitat: Wir kennen es alle. In Filmen gibt es Filmzitate, die man hin und wieder gerne aufschnappt.

FSK: Ein jeder Film hat bestimmte Altersbeschränkungen. Da meine Software ein reines Verwaltungsprogramm sein wird, und es auch mehrsprachig angeboten wird, so wollte ich den Anwendern überlassen, dass sie bezüglich der Altersbeschränkungen selbst Stammdaten anlegen können. So komme ich nicht in Verlegenheit auf der Client-Seite etwas zu vergessen bzw. auszulassen. Denn jedes Land, jede Kultur hat unterschiedliche Definitionen bezüglich der Altersfreigaben.

Zwischentabelle:
FilmDetail_FilmFassung_FilmZitat: Hier sollen alle Informationen gebündelt werden.

Problem: Schauen wir uns mal die Tabelle FilmZitat an. Je nach dem, welche Fassung wir gerade vor uns liegen haben, desto eher verschiebt sich das mit dem Zitat. Zum Beispiel kann es passieren, dass bei einer TV-Fassung so viel und extrem geschnitten wurde, dass dort bestimmte Zitate wegfallen, die man nur in der Fassung Uncut zu hören bekommt. An dieser Stelle weiß ich nicht, wie ich eine Beziehung herstellen soll. Wenn ich recht überlege, ist die Tabelle FilmZitat von der Tabelle FilmFassung abhängig. Ode was meint ihr?

 

[Sophus]

Mag mir keiner mehr Helfen? Die Hilfe hat sehr stark nachgelassen, was ich sehr schade finde. Woran ist es gescheitert?

 

[akretschmer]

Mag mir keiner mehr Helfen? Die Hilfe hat sehr stark nachgelassen, was ich sehr schade finde. Woran ist es gescheitert?

An der fehlenden Signatur. Sowas geht ja gar nicht!

 

[Sophus]

Ach so Ja, meine geistigen Mitarbeiter arbeiten mit Hochdruck daran

 

[Distrilec]

In dem Sinne ist es nicht gescheitert... Sondern ich habe auch nicht immer Zeit
Bin ja nicht verpflichtet hier immer Zeit zu haben, oder ?

Bis jetzt sehe ich da aber auch kein Problem... (Im wahrsten Sinne des Wortes... Das Bild ist nämlich nich da)

 

[Sophus]

Das Bild ist nicht zu sehen, weil die Seite (fotos-hochladen.de) offline ist. Und zu der Zeit. Ich verstehe das voll und ganz. Es gibt auch wichtigeres im Leben. Und niemand ist verpflichtet, dass man hier was schreibt. Ich stelle nur fest, dass die Aktivität stark nachgelassen hat, während am Anfang meines Threads noch kräftig geschrieben wurde.

 

[Walter]

Das Bild ist nicht zu sehen, weil die Seite (fotos-hochladen.de) offline ist

Lade es doch einfach hier im Forum hoch. Beim schreiben eines Beitrags einfach auf "Datei hochladen" klicken.

 

[Sophus]

Hallo Walter, das kann ich sehr gerne tun. Danke für den Hinweis.

 

[Distrilec]

Also ich seh da so erstmal nichts zum meckern... Vllt. haben andere ja ein besseres Auge...

 

[Sophus]

Also bei FilmZitate komme ich ein wenig ins Schleudern. Nach meinem Verständnis sind FilmZitate von der FilmFassung abhängig. Wenn wir mal an einen Horrorfilm denken, den gibt es mal in FSK16, FSK18, Uncut, Kino-Version, TV-Version etc. Also unterschiedliche Fassungen. Nun weiß ich nicht, ob ich die FilmZitate richtig in Beziehung gesetzt habe. Was meinst du dazu, Distrilec?

 

[Distrilec]

Ich finde das schon in Ordnung so. Kann ja sein das es Zitate gibt, die nur in der Directors Cut-Version zu sehen sind... (als Beispiel)