Mit SQLiteDatabaseBrowserPortable habe ich die Felder auch schon in einer Tabelle angelegt.
Meine Fragen hierzu:
- reicht es alle Felder in einer Tabelle zu belassen oder sollte ich eher auf 2 Tabellen (Tapes, Tracks) umsteigen?
- was nehme ich als Primary Key?
@luemmel76: bei Deinem jetzigen Design hast Du einen zusammengesetzten Primärschlüssel (tapenumber, tracknumber); ein Zeichen dafür, dass man noch weiter normalisieren kann. Wie Du schon sagst, wären zwei Tabellen (Tape, Track) sinnvoll, wobei man üblicherweise noch eine generische ID als Primärschlüssel für jede Tabelle einführt.
@luemmel76: Ich würde die Tabellen `track` und `tape` nennen. Ähnlich wie bei Klassen in der objektorientierten Programmierung beschreibt das Schema ja *einen* Datensatz. Spätestens wenn man ein ORM einsetzt fällt einem dieser Zusammenhang auf und die Abweichung in der Namensgebung.
Ausserdem würde ich mich auf Kleinbuchstaben bei SQL-Bezeichnern beschränken. Der Standard sagt eigentlich das die Namen „case insensitive“ sind, aber es gibt DBMS die das anders handhaben, manchmal abhängig von Einstellungen. Bei den Namen fehlen für meinen Geschmack auch Unterstriche die die Worte trennen um das lesbarer zu machen beziehungsweise sind die Präfixe eigentlich überflüssig wenn sie nur den Tabellennamen wiederholen. Das es sich bei `trackstart` um den Start eines Tracks handelt, wird ja schon dadurch deutlich das diese Spalte in der Tabelle `tracks` steht.
Bei SQLite würde ich das AUTOINCREMENT weg lassen. Falls Du es beibehältst, solltest Du zumindest die Folgen davon in der Dokumentation nachlesen. Irgendwie kann ich auch nicht glauben das die Spaltentypen alle TEXT sein sollen‽
Das bei `tapes.tapenumber` ist auch nicht nur ein anderer Name `tapes.tape_id` sondern da würde man eine Fremdschlüsselbeziehung deklarieren.
luemmel76 hat geschrieben:
Ich habe die Anmerkungen berücksichtigt:
Noch nicht ganz: track.tape_id ist noch nicht als Fremdschlüssel definiert (und sollte dann auch INTEGER sein, nicht NUMERIC). Guck Dir dazu aber auch das Thema "PRAGMA foreign_key" in der SQLite-Dokumentation an. So praktisch SQLite sein kann, gar so standardkonform ist es ja nun nicht.
Zusatzfrage: können die Felder, die Du jetzt als NUMERIC definiert hast, tatsächlich alle auch Zahlen mit Nachkommastellen enthalten? Wenn nicht, dann wäre INTEGER vorzuziehen.
@bb1898: Auch wenn SQLite im Verhalten nicht immer Standardkonform ist und das eine oder andere an SQL-Syntax einfach ignoriert, so ist so ein FOREIGN KEY immerhin noch Dokumentation für den Leser und da das auch im Schema gespeichert wird, können eventuell auch Werkzeuge wie ORM-Bibliotheken mit der Information etwas anfangen. Ist bei den Datentypen ja im Grunde genau so. Auch da würde ich möglichst genau angeben was in einer Spalte erwartet wird, auch wenn sich SQLite da am Ende nicht wirklich darum schert ob man eine Zahl oder eine Zeichenkette speichert.