nicht angemeldet
Hi Erik,
'b' ist unique. Aber die Zerlegung in die drei Tabellen hat
durchaus ihren Sinn.
Denn nicht nicht für jedes 'b' sind in allen drei Tabellen
Werte.
um das zu modellieren, gibt es den Wert NULL und die Eigenschaft einer Spalte, NULL-Werte aufzunehmen.
(Das wird üblicherweise über ein zusätzliches FLAG pro Spalte realisiert, kostet also ein bißchen Platz.)
In einer Tabelle sind zudem (sofern sie vorhanden sind) sehr
große Werte und eine Tabelle hat (sehr kleine) Werte die sehr
oft geändert werden müssen.
Und dann ist es doch ein Vorteil, wenn ich eine 'kleine' Zeile
habe, die geändert werden muss, die vielleicht 1 kb hat, als
wenn ich eine Zeile ändere die ca. 50 kb hat, oder sehe ich
das falsch?
Ich würde sagen, das ist Aufgabe des RDBMS, dies effizient umzusetzen.
Natürlich solltest Du dann nicht mit SELECT * alle Felder holen, wenn Du nur einzelne Felder änderst.
Aber die anderen Felder sollten von einem UPDATE einer einzelnen Spalte eigentlich nicht betroffen sein (idealerweise).
Mag sein, daß ein konkretes Datenbanksystem (oder ein konkreter Tabellentyp!) davon profitieren würde, wenn Du die am häufigsten geänderte Spalte als letzte deklarierst - falls die Werte aller Spalten einer Zeile gepackt hintereinander in einem Speicherbereich abgelegt werden und dies in der Reihenfolge der Spalten-Deklarationen, dann müßten in diesem Falle zumindest nur sehr selten unveränderte Feldinhalte verschoben werden.
Also: Solange Du keine irre hohen Performance-Ansprüche hast, würde ich auf eine Zerlegung in mehrere Tabellen erst mal verzichten. (Es sei denn, der Performance Tuning Guide Deines RDBMS rät Dir explizit dazu, es so zu machen ...)
Viele Grüße
Michael