Frage zu Aufbau SQLite Datenbank

Installation und Anwendung von Datenbankschnittstellen wie SQLite, PostgreSQL, MariaDB/MySQL, der DB-API 2.0 und sonstigen Datenbanksystemen.
Antworten
luemmel76
User
Beiträge: 22
Registriert: Freitag 26. Februar 2016, 17:42
Wohnort: Südhessen

Hallo zusammen,

ich möchte eine Datenbank (SQLite) aufbauen mit den Feldern:

Code: Alles auswählen

tapenumber;tapetype;tapelength;tapespeed;tapeside;tracknumber;tracktitle;trackstart;tracklength
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?


Gruß
Thilo
Sirius3
User
Beiträge: 17711
Registriert: Sonntag 21. Oktober 2012, 17:20

@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
User
Beiträge: 22
Registriert: Freitag 26. Februar 2016, 17:42
Wohnort: Südhessen

Danke Sirius3

müsste ja dann so aussehen, oder?

Tabelle 1:

Code: Alles auswählen

CREATE TABLE `tapes` (
	`ID`	INTEGER PRIMARY KEY AUTOINCREMENT,
	`tapenumber`	TEXT,
	`tapetype`	TEXT,
	`tapelength`	TEXT,
	`tapespeed`	TEXT,
	`tapeside`	TEXT
);
Tabelle 2:

Code: Alles auswählen

CREATE TABLE `tracks` (
	`ID`	INTEGER PRIMARY KEY AUTOINCREMENT,
	`tapenumber`	TEXT,
	`tracknumber`	TEXT,
	`tracktitle`	TEXT,
	`trackstart`	TEXT,
	`tracklength`	TEXT
);
Gruß
Thilo
Sirius3
User
Beiträge: 17711
Registriert: Sonntag 21. Oktober 2012, 17:20

Statt tapenumber in tracks würde man tape_id nehmen.
luemmel76
User
Beiträge: 22
Registriert: Freitag 26. Februar 2016, 17:42
Wohnort: Südhessen

Danke Sirius3 :-)
BlackJack

@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
User
Beiträge: 22
Registriert: Freitag 26. Februar 2016, 17:42
Wohnort: Südhessen

Ok, befasse mich erst seit Freitag aktiv mit SQLite (und Datenbanken), daher blutiger Anfänger ;-)

Ich habe die Anmerkungen berücksichtigt:

Code: Alles auswählen

CREATE TABLE `tape` (
	`id`	INTEGER,
	`number`	NUMERIC,
	`type`	TEXT,
	`length`	NUMERIC,
	`speed`	NUMERIC,
	`side`	TEXT,
	PRIMARY KEY(id)
);
und

Code: Alles auswählen

CREATE TABLE `track` (
	`id`	INTEGER,
	`tape_id`	NUMERIC,
	`number`	NUMERIC,
	`title`	TEXT,
	`start`	NUMERIC,
	`length`	NUMERIC,
	PRIMARY KEY(id)
);
bb1898
User
Beiträge: 199
Registriert: Mittwoch 12. Juli 2006, 14:28

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.
BlackJack

@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.
Antworten