Ein paar grundlegende Fragen

Hi

Ich möchte eine kleine Datenbank erstellen und erhoffe mir ein paar grundlegende Tipps, damit ich nicht erst wild drauflos erstelle und dann merke, dass von Anfang an alles einfacher gegangen wäre oder spätere Erweiterungen sogar unmöglich sind.

Meine bisherigen Erfahrungen bestehen aus zwei Tutorials mit MySQL (XAMPP): als erstes, quasi das „Hallo Welt“ aller Datenbanken, meine Adressen sind jetzt schön sauber sortiert. Als zweites, kann ich die Lagerbestände unterschiedlicher Waren und Lager redundant ablegen und abfragen.

Meine DB soll ca. 2.000 – 3.000 Datensätze haben. Je Datensatz sind 35 Datenfelder geplant. Angemeldete User sollen Datensätze erstellen und bearbeiten können.
Die weiteren Anforderungen an meine DB veranschauliche ich mal anhand einer Film-DB, da sich darunter jeder was vorstellen kann.

Meine aktuelle Idee ist, eine Tabelle zu erstellen, welche z. B. folgende Felder hat: Filmtitel (en), Filmtitel (de), Filmtitel (fr), usw, Erscheinungsjahr, Regisseur, Schauspieler
Jetzt taucht das erste „Problem“ auf, unterschiedliche Filme haben eine unterschiedliche Anzahl an Schauspielern. Wie kann ich in einem Datenfeld je Datensatz eine unterschiedliche Menge an Informationen unterbringen? Gibt es als Datenfeldtyp statt einem String auch sowas wie eine Liste?

Dann kann es Datenfelder geben, die leer bleiben. Entweder weil die Information aktuell nicht bekannt ist und erst später nachgereicht wird oder es einfach keine Information dazu gibt. Ich habe gelesen, dass einige Datenbanken eher empfindlich auf fehlende Informationen reagieren. Kommt MySQL damit klar oder ist es sinnvoll einen Dummy dafür einzurichten?

Bisher habe ich die Daten immer nur im Quelltext direkt geschrieben. Wie programmiere ich ein Eingabeformular zum befüllen der DB? Mit PHP? Kann ich das auch erst mal am PC mit Excel voreingeben und dann portieren oder mache ich mir damit unnötig viel Arbeit?

Da das Ganze irgendwann auch mal ein bisschen nach was aussehen sollte, dachte ich mir, dass ich die Seite, mit der die Daten eingegeben, bearbeitet und ausgegeben werden mit Joomla! (von dem ich aktuell noch viel weniger Ahnung habe als von MYSQL) erstelle. Gibt es da was zu beachten? Soweit ich weiß braucht Joomla eine eigene Datenbank. Heißt das, dass ich zwei Datenbanken auf dem Server des Hosters brauche oder kann ich die Joomla!-DB und die Film-DB das in der selben DB speichern?

Das A und O sollen später bei der Suche umfangreiche Suchmöglichkeiten sein, die alle der folgenden Bedingungen erfüllen:
- Zeige Filme von 2008 - 2011
- Aus Canada
- Mit italienischen Untertiteln
- In S/W
Kann man das mit EINER Tabelle umsetzen?

Grüße
Bifi

 

Erstes Problem: was ist mich weiteren Sprachen?

Gibt es , aber nicht für Anfänger. Lerne Normalisierung. Das ist direkt das Google-Stichwort. Du brauchst 3 tabellen:

• Filme
• Schauspieler
• Filem_Schauspieler

Die ersten beiden enthalten primary Keys, die in der dritten als Foreign Key auftauchen. So kann jeder Film beliebig viele Schauspieler haben.

Die Felder bleiben leer, NULL.

PHP ist beliebt für sowas.

Beides geht.

Grad a schlechtes Beispiel, weil hier nicht viel zu normalisieren ist. Normalerweise bestehen Datenbanken aus mehreren Tabellen, eben um zu normalisieren.



Wenn Du SQL lernen willst: vermeide MySQL. Das macht das Gehirn krank.

 

Im Moment fällt mir für Listen in einer relationalen Datenbank keine Anwendung ein. Kannst du mir da mal ein Stichwort/Link geben?

Für einen schnellen Einstieg empfehle ich das bei PHP enthaltene SQLite. Das sollte auch bei jedem normalen Hoster laufen. Der Funktionsumfang ist im Vergleich zu z.B. PostgreSQL deutlich kleiner. Dafür kannst du aber alles was du damit gelernt hast auch in jeder anderen großen Datenbank* nutzen.

*Nein. MySQL gehört nicht dazu.

 

Danke euch beiden für die wirkliche schnelle Antwort. Finde ich echt klasse.

Ich habe mir grade mal den Wiki-Artikel zur Normalisierung bei Datenbanken zu Gemüte geführt. Mir raucht der Kopf. Puhhhh. Ich habe immer wieder das Gefühl gehabt, alles zu verstehen, aber ich schaffe es aktuell noch nicht alles in eigene Worte zu fassen. Ich habe den Artikel ausgedruckt und unter das Kopfkissen gelegt - ich glaube zwar nicht, dass das Wissen im Schlaf kommt, aber ich glaube an den Placebo-Effekt

Da ich nicht nach allen 30 Spalten filtern sondern nur nach 6 Spalten filtern möchte, muss ich dann für jeden möglichen Filter eine Tabelle anlegen? Also:

• Tabelle_Jahr
• Tabelle_Land
• Tabelle_farbe_sw

Mein Gehirn ist schon krank, ist das eine gute Voraussetzung oder eher hinderlich? Was ich eigentlich meine: Warum macht MySQL das Gehirn krank(er)?

Auch hier musste wieder Wiki herhalten (ich überlege grade wie ich vor 20 Jahren ohne Wikipedia recherchiert habe - aber das gehört nicht zum Thema ).
Ich vermute dass SQLight nicht das richtige ist, da SQLight "über keine Verwaltung von Benutzer- und Zugriffsberechtigungen auf Datenbank-Ebene" verfügt, da ich nur angemeldeten Benutzern schreibrechte geben will. Wenn ich Wiki weiterhin richtig verstanden habe, kann nur ein Benutzer gleichzeitig an der Datenbank arbeiten, also können unterschiedliche Benutzer nicht an verschiedenen Datensätzen arbeiten. Desweiteren steht bei Wiki, dass "Fehlerhafte Eingaben werden in der Regel akzeptiert und in Zeichenketten umgewandelt". Ich denke, dass Fehlerhafte Eingaben durchaus abgefangen werden sollten, denn ein "2012" ist kein "Zweitauschenzwölf" und erst recht kein "zwanzigzwölf". Durch solche 'Fehlerhafte Eingaben' wird das filtern doch schwer bis unmöglich gemacht, oder habe ich da was komplett falsch verstanden?

 

Nein. Das Beispiel war schlecht, weil je Film ja nur ein Erscheinungsjahr, ein Land (wo es herkommt) und entweder Farbe oder SW ist..
Wobei - Land, da können ja auch mehrere sein, oder?

Dann sowas wie Tabelle Film mit einer eindeutigen ID und eine weitere Tabelle mit 1 bis N Zeilen: je Film und Land eine Zeile.

MySQL ist halt 'billig' im Sinne von billig gemacht. Es macht viele Dinge sehr komisch, z.B. akzeptiert es Dinge, realisiert diese aber nicht. Bestes Beispiel: Check-Constraints. Es prüft wenig auf Datenkonsistenz (ein String, der nicht in ein längendefinertes Stringfeld paßt, wird kommentarlos abgeschnitten), es kann viele moderne Suchverfahren nicht, es hat nur rudimentäre Datentypen und eine ungewisse Zukunft (Oraggle).
Viele Dinge kann es nicht, wie z.B. analytische Abfragen (CTE, Window-Funktionen), GIN / GIST - Indexe und so weiter).
Und das ganze wirre Zeugs mit Storage-Engines: MyISAM kann Volltext aber keine Trasaktionen, InnoDB kein Volltext, Blackhole speichert schnell und belegt keiner Platz, findet aber keine Daten mehr. Krank.

Ich sehe hier @work täglich Zeugs mit MySQL und den Problemen, die es macht, wo ich denke: mit PostgreSQL hätten es die Kunden um Welten einfacher. Eine Engine, die mehr kann als alle MySQL-Verirrungen zusammen. Sehr viel mehr.

 

Die Zugriffsberechtigung erteilt also deine Anwendung und nicht die Datenbank. Selbst bei PostgreSQL oder auch MySQL greift im Normalfall nur der Benutzer "Anwendung" direkt zu.

1. Lesezugriffe sind davon nicht betroffen
2. Wie viele Editoren soll es gleichzeitig geben? 10-20? Das steckt SQLite problemlos weg. Kritisch ist die Datenbankgröße relativ zur Festplattengeschwindigkeit.

Das ist grundsätzlich schon richtig. Aber SQLite besitzt eine überschaubare Menge an Datentypen und beherrscht Check-Constraints. Daher ist eine Prüfung durch die Datenbank auf den richtigen Datentyp problemlos möglich.

Auf der sicheren Seite bist du mit PostgreSQL. Die Lernkurve bei SQLite ist aber deutlich flacher.

 

Im 'Normalfall' ja. Man kann aber auch eine Zugriffs-API sich bauen, indem man a) Benutzer in der DB anlegt, b) diesen alle Rechte entzieht und c) als Super-User Funktionen schreibt, die die Benutzer nutzen können. (Security Definer). Innerhalb dieser kannst Du dann anhand des aufrufenden User entscheiden, was dieser machen darf und was nicht. Die User können also nur noch über diese Funktions-API zugreifen, sie sehen keine Tabellen mehr. Zum Beispiel kann man dann auch je Record vermerken, wer ihn angelegt hat, wer ihn ändern darf etc.

Ich kenne eine nicht gerade kleine Firma, die das so machen in ihrem Webshop. Der Vortrag dazu zur PGConf 2013 war sehr interessant.

Hint: Schrei vor Glück ;-)

 

Mir das grundsätzliche Konzept schon klar. Genauer hab ich mich Damit allerdings noch nicht auseinander gesetzt. Aber hältst du die Methode für Einsteiger freundlich?

 

Nein. *Lach*