Hallo Andreas
Andreas Borutta schrieb:
Bitte gehe auf die von mir genannten Argumente ein, wo ich schreibe,
dass ich keinen guten Grund sehe, bewußt eine für menschliche
Verwalter (ich schrieb explizit nicht von Anwendern) schlechter
lesbare (Benennungen, Reihenfolge) und somit schlechter wartbare
Struktur anzulegen.
Auf diese Deine Aussage bin ich bis jetzt noch nicht eingegangen und
will das gerne nachholen:
Es kann keine Rede davon sein, "eine (...) schlechter wartbare Struktur
anzulegen". Die Aussage lautete ganz anders: "die Benennung von Feldern
und ihre Reihenfolge in der Tabelle ist für das Funktionieren der DB
absolut belanglos" - das war sinngemäss der Inhalt der Aussage. Dazu
folgende Bemerkungen:
* Eine klar gegliederte Struktur kann nie schaden - doch darf diese
Gliederung (im Sinne von: Reihenfolge der DB-Felder) nicht
überbewertet werden. Aus zwei Gründen: erstens sieht der User nie
die Tabellen, denn er wäre - wie ich schon verschiedentlich betont
habe - bei einer gut gemachten DB-Applikation überfordert: da
müsste er sich mit mehreren Tabellen herum schlagen, müsste
Primärschlüsselwerte auslesen und sie als Sekundärschlüsselwerte
in anderen Tabellen einfügen, und derlei Spässe mehr. Dafür bietet
ein DB-System die Formulare (im wesentlichen für die Eingabe) und
die Reports (im wesentlichen für die Ausgabe). In diesen Objekten
"zerschiesst" man bewusst die schön aufgebaute Struktur, damit der
User versteht, was er eingeben soll oder was bekommen kann. Die
Gliederung der Felder kann völlig anders sein als in den Tabellen.
Es liegt am Entwickler, das Ganze im Hintergrund wieder
auseinander zu bröseln. Zweitens: was ist denn eine gut lesbare
Struktur? Das ist kein objektives Kriterium. Nimm als ganz
einfaches Beispiel einen Adressdatensatz: Amerikaner und Engländer
setzen die PLZ (dort Zip genannt) ganz anders als wir in
Zentraleuropa. Oder die Russen: ihre Adressstruktur ist völlig auf
den Kopf gestellt und damit für uns sehr gewöhnungsbedürftig:
zuoberst wird das Land angegeben, dann die PLZ und die Stadt, auf
der nächsten Zeile die Adresse, und zuunterst der Name des
Empfängers - auch eine Logik, aber aus unserer Sicht wie gesagt
sehr gewöhnungsbedürftig. Das ergäbe in einer Adress-DB eine
völlig andere Struktur als bei uns. Was ist nun eine "gut lesbare
und damit wartbare Struktur"? Doch eine sehr subjektive Angelegenheit.
Dazu ein Beispiel: nimm eine Adress-DB. Die Normalisierung verlangt
mindestens zwei Tabellen: eine mit den personenbezogenen Angaben (Name,
Vorname, Adresse, Telefonnummern, ..., sowie den Sekundärschlüssel auf
die Ortstabelle) und eine für den Ort (PLZ, Ortsname, evtl. Stadtteil).
Was ist jetzt die "richtige" Struktur? Hängt doch sehr vom
Anwendungsfall ab: für Adressetiketten ist eine andere Reihenfolge
sinnvoll als für ein Mitgliederverzeichnis. Trotz dieses Einwandes
spricht nichts dagegen, sich auch die Reihenfolge gut zu überlegen und
für eine logisch erscheinende (das ist subjektiv, nicht objektiv)
Reihenfolge zu entscheiden. Gerade weil ein nachträgliches "Einschieben"
nicht ohne weiteres möglich ist, muss ich aber im Sinne der
Aufwandminimierung auch akzeptieren, dass in der Testphase noch
Änderungen auftreten, die diese Struktur "zerschiessen". Beispiel: ich
habe mich ursprünglich dafür entschieden, PLZ und Ort im gleichen Feld
zu erfassen (warum auch immer - es geht ums Prinzip). Nun zeigt aber die
Testphase, dass ich sie doch auseinander nehmen muss. Dann habe ich in
der Tabelle nicht die übliche Struktur PLZ - Ort(sname). Für die
Leistungsfähigkeit der DB-Applikation ist das belanglos. Wichtiger
scheint mir da, in der Entwurfsansicht nicht nur die Spalten Feldname
und Feldtyp zu beachten, sondern ganz speziell die dritte Spalte
"Beschreibung": hier soll man Hinweise auf Bedeutung und Zusammenhänge
der Felder notieren.
* Was sind "gut lesbare Feldnamen"? Der Entwickler wird darunter
etwas Anderes verstehen als der User. "Name ist Schall und Rauch"
ist man mit Johnny Goethe versucht zu sagen - solange der
Entwickler mit seiner eigenen Namensgebung klar kommt. Dem
Entwickler ist es i.a. wichtiger, über die Namen einen Hinweis auf
die Struktur zu erhalten: zu welcher Tabelle gehört ein Feld? Hat
es eine spezielle Aufgabe (z.B. Sekundärschlüssel), und auf welche
Tabelle referenziert es in diesem Fall? Das von mir empfohlene
Buch von Hölscher schlägt diesbezüglich eine aus User-Sicht
ungewohnte, aus Entwicklersicht aber sehr sinnvolle Konvention
vor. In den "User-Interfaces" - sprich Formularen und Berichten -
sollte das Ganze aber im Klartext, möglichst in epischer Breite,
daher kommen, damit der User klar weiss, worum es geht.
Fazit: ich bin der letzte, der der Schludrigkeit das Wort redet - aber
die Ansicht, was eine gut lesbare und wartbare Struktur sei, und was
sprechende Namen seien, hängt von der Funktion ab, die ich wahrnehme,
und von meinen Kenntnissen und Fertigkeiten, und: von meinem
sozio-kulturellen Hintergrund. Kurz: die Bedeutung einer solchen
Forderung darf nicht überbewertet werden.
Ich hoffe, dass ich damit etwas klären konnte.
Freundlich grüsst
Ernst
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@de.openoffice.org
For additional commands, e-mail: users-h...@de.openoffice.org
