Hallo Andreas
Andreas Borutta schrieb:
Ernst Hügli schrieb:
Ich verstehe Dein Problem nicht: "JJJJ" als Datentyp gibt es weder in
einer Tabellenkalkulation noch in der Kalenderrechnung noch in der
Mathematik:
Das Werkzeug "PHPmyAdmin" bietet beim Anlegen einer Tabelle YEAR als
Datentyp an - neben DATE, DATETIME, TIMESTAMP, TIME
Selbstverständlich schreibe ich das nicht im Sinne von "aber ...".
Ich berichte nur über diese "Entdeckung".
Das Interface von PHPmyAdmin zum Anlegen von Tabellen ist drastisch
umfangreicher als jenes von Base.
Ich habe mich ein bisschen schlau gemacht in dieser Sache. Obschon
dieses Thema eigentlich abgehakt ist, komme ich nochmals darauf zurück,
weil ich denke, man kann an diesem Beispiel wunderschön sehen, wie
Design, Struktur und Implementation zusammenspielen müssen:
Nach meinen Informationen kann man in einem mit PHPMyAdmin angelegten
Feld vom Typ YEAR Jahrzahlen zwischen 1901 und 2155 ablegen. Was
bedeutet das? Intern wird eine Zahl von genau 1 Byte Länge, also ein
sog. TINY INTEGER gespeichert mit Werten zwischen 0 und 255 (= 2^8 - 1).
Dies bedeutet: für die *Darstellung* am Bildschirm wird zum
gespeicherten Wert einfach 1900 addiert (ich vermute mal, dass $00000000
nicht benutzt wird). So weit so gut. Jetzt aber kommt die alles
entscheidende Frage: wofür willst Du die Datenbank später einsetzen
(können)?
Zunächst ist klar: Dein Freund, der Komponist, will damit seine Werke
verwalten. Wenn es dabei bleibt, dürfte wohl kein Problem mit diesem
Datentyp entstehen. Sollte aber jetzt ein Musiker (kein Komponist!) auf
die Idee kommen, die Werke seines Repertoires damit zu erfassen, dann
gibt es sehr wohl Probleme: er schafft es - trotz Labelfeld "Jahr ..."
nicht, die Jahrzahlen für Kompositionen von Bach, Händel, Haydn, Mozart,
Beethoven, Brahms, Schubert, Liszt, .... einzugeben.
Schlussfolgerung: aus dem Zusammenspiel von Design (= präzise Definition
der Anwendungssituationen und Übersetzung davon in eine DB-Struktur von
verknüpften Tabellen mit Feldern) und genauer Kenntnis dessen, was mit
den einzelnen, vom DB-System angebotenen Strukturelementen (hier:
Feldtypen) realisierbar ist, ergibt sich die flexible Implementation
(Achtung: es geht nicht um richtig oder falsch: für Deinen konkreten
Erstanwendungsfall mag YEAR der richtige Datentyp sein, aber er ist für
die Verallgemeinerung unflexibel!). Nun könnte man den (voreiligen)
Schluss ziehen wollen, dass es Unsinn sei, überhaupt einen solchen
Datentyp zu implementieren. Muss es nicht: für Buchhaltungs- oder
Mitglieder-/Mitarbeiterdaten (z.B. Eintritts- oder Geburtsjahr) ist es
wohl keine wirkliche Einschränkung, wenn man sich auf Jahre ab 1901
beschränkt. Es hängt ganz einfach vom Anwendungsfall ab, ob es Sinn
macht oder nicht.
Schlussfolgerung: obschon mit YEAR ein spezifischer Feldtyp für Jahre
verfügbar ist, würde ich den Typ SMALL INTEGER (2 Byte, Werte zwischen 0
und 65'535) vorziehen. Sowohl der Mehrverbrauch an Speicher wie auch die
reduzierte Performance fallen gegenüber der erhöhten Flexibilität in
Deinem Anwendungsfall nicht ins Gewicht. Dafür musst Du im Gegenzu
sicher eine noch zu definierende Gültigkeitsprüfung implementieren,
damit nicht plötzlich Werte wie 21'456 oder ähnlich eingegeben werden -
bei SMALL INTEGER würde das DB-System einen solchen Wert widerstandslos
akzeptieren.
Freundlich grüsst
Ernst
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
