[MySQL 4.1] Geeignete Feldtypen, Indizes usw.

[KingRaptor]

Hi,

ich plane momentan ein etwas größeres Projekt, das u.A. auch eine Bildergalerie beinhalten soll. Nun will ich halt die DB-Struktur von Anfang an richtig gestalten, also habe ich einige Fragen:

1. Ich habe gelesen, dass Felder mit festen Größen besser sind, als welche mir variablen Größen. Also dass man eher CHAR als VARCHAR benutzen soll. Stimmt das so? Was wäre, wenn ich einen Namen mit einer festen Grenze (also zB maximal 32 Zeichen) speichern will: Wenn ich CHAR(32) benutze und einen Namen mit 20 Zeichen habe, würden ja 12 Leerzeichen angehangen. Ist es also besser diese dann nach der Abfrage per trim() zu löschen oder lieber doch direkt VARCHAR(32) benutzen? Wie würde denn eine WHERE Abfrage bei so einem Typ aussehen? Würde "`name` = 'abc'" ein Ergebnis liefern, wenn abc + die auffüllenden Leerzeichen in der Tabelle stünde?

2. Ich habe einige Felder, in denen ich Einstellungen speichern will, also einstellige Werte (meistens nur 0 oder 1 evtl. auch mehr). Wie wären die am besten zu speichern? TINYINT oder CHAR(1)? Oder etwas ganz anderes?

3. Indizes: Also ich habe in jeder Tabelle einen PRIMARY KEY id Feld. Jetzt gibt es aber noch anderen Möglichkeiten für weitere INDEX Felder. Z.B. sind alle Fotokommentare mit der dazugehörigen Bild-ID in einer Tabelle gespeichert, also wäre es ja gut, wenn dieses Bild-ID Feld auch einen INDEX bekommt, weil ja eigentlich nur so auf die Tabelle zugegriffen wird. Jetzt haben ich irgendwo mal etwas von 1. Index 2. Index etc. gelesen. Haben mehrere Indizes also verschiedene Prioritäten, so dass ich mir da auch Gedanken zu machen muss oder ist das egal?

So, ich denke, das wars fürs erste :-)

MfG
Tobi

[TobiaZ]

Ist es also besser diese dann nach der Abfrage per trim() zu löschen

In den meisten fällen wohl kaum.

Würde "`name` = 'abc'" ein Ergebnis liefern, wenn abc + die auffüllenden Leerzeichen in der Tabelle stünde?

Ausprobieren!

2. Ich habe einige Felder, in denen ich Einstellungen speichern will, also einstellige Werte (meistens nur 0 oder 1 evtl. auch mehr). Wie wären die am besten zu speichern? TINYINT oder CHAR(1)? Oder etwas ganz anderes?

schau dir auchmal ENUM und SET an.

[KingRaptor]

Ups, ich hab überlesen, dass die CHAR Leerzeichen bei einer Abfrage automatisch gelöscht werden. Ich würde nur gerne wissen, ob es Sinn machen würde CHAR in bestimmten Fällen zu nutzen, also dort, wo die Maximallänge in den meisten Fällen fast oder ganz erreicht wird. Ich denke, bei Namen würde es weniger Sinn machen, weil die eben auch kurz sein können, oder eben oft kurz sind und der zusätzliche Speicherplatz, den CHAR brauch, die evtl. Vorteile wieder zunichte macht.

[web-prinz.de]

Hallo KingRaptor,

MySQL unterscheidet zwischen dynamischen und statischen Tabellen. Solange deine Tabelle keine varchar-, text- oder blob-Felder enthält, ist sie statisch. Was heißt das?
Stell dir vor du hast eine Tabelle mit 2 Feldern vom Typ Integer. Ein Integer-Feld nimmt 4 Bytes weg. Ein Eintrag in deiner Tabelle verbraucht also 8 Bytes auf deiner Festplatte. Wenn MySQL nun nach gewissen Einträgen in deiner Tabelle sucht, dann weiß es dass es nach genau 8 Bytes immer den nächsten Eintrag findet.
Besitzt deine Tabelle wiederum ein Feld vom Typ varchar, dann muss es zunächst immer sehen wie lang das Feld ist um den Anfang des nächsten Tabelleneintrages auf der Festplatte zu finden.
Dieses zusätzliche "Nachsehen" benötigt natürlich Zeit und macht sich bei vielen Einträgen schon bemerkbar.
Wenn du nun einmal zwischen der Verwendung eines Char- und Varchar-Datentypes schwankst, solltest du einerseits auch den Datentyp Enum in Betracht ziehen. Es verbraucht nur 2 Bytes und kann ziemlich viele Werte aufnehmen. Wenn du vorab die Menge der möglichen Werte kennst (wie bei Einstellungen etc.) dann kann es eine Alternative sein.
Andererseits solltest du beachten, dass die Verwendung eines Char-Feldes (statt varchar) nur wirklich etwas bringt, wenn du sonst nur Datentypen mit fester Länge in der Tabelle verwendest. Vergiss auch nicht dass du dir deine Performance mit mehr Speicherverbrauch erkaufst. Dies kann bei sehr großen Projekten auch schnell ein Problem werden.

Noch was zum Thema "Speichern von Einstellungen". Ein Feld vom Typ Tinyint kann maximal 256 Werte (8 Bit) speichern. D.h. wenn es sich bei den Einstellungen um boolsche Werte handelt (true oder false, ja oder nein, ein oder aus), dann kannst du in einem tinyint-Feld bitweise 8 Einstellungen speichern.

Thema Indizes: Sehr wichtig wenn es um performante Suche geht!! Das kann man aber nicht mal so eben erklären. Betrachte deine Datenbankabfragen, ermittel die Felder über die du bei deinen Abfragen die Daten selektierst (where name = ... ; where feld > ...) und die schätze die Häufigkeit mit der diese Abfrage ausgeführt wird.
Über die Felder, die kein Schlüssel sind und trotzdem sehr häufig in deinen Abfragen vorkommen, solltest du möglicherweise einen Index anlegen. Allerdings gilt es zu berücksichtigen, dass Einfüge- und Änderungs-Operationen dadurch langsamer werden und Indizes meistens nicht wenig Speicherplatz wegnehmen.

Da du dich für dieses Thema scheinbar sehr interessierst, empfehle ich dir das Buch High Performance MySQL von Jeremy Zawodny und Derek J. Balling. Die Beiden haben Ahnung von der Thematik und haben u.a. Erfahrungen bei Yahoo! sammeln dürfen. Zum Einstieg in die Thematik ein echt gutes Werk!


P.S. Was nun wieviel Bytes schluckt, kannst du hier nachlesen.