Matthias Müller schrieb:
>>>> Dennoch finde ich, dass es der Nachhaltigkeit dient, wenn die
>>>> Datenfelder der Tabelle in einer sinnvollen Reihenfolge stehen und
>>>> sprechende Namen tragen.
>>>
>>> Das kann, muss aber nicht so sein.
>>
>> Kannst Du bitte ein konkretes Beispiel nennen, wo eine nicht sinnvolle
>> Reihenfolge und schlechte Bezeichner von Datenfeldern die Wartbarkeit
>> der Tabelle /nicht/ verschlechtern?
> Der Endanwender sieht den Entwurf, die Datenbank nicht. Er sieht Formulare
> und
> Ein- und Ausgabemasken. Der Entwickler der Datenbank entscheidet wie
> Datenfalder angeordnet werden. Die DB-Engine macht bestimmte Vorgaben, zB
> weil durch sie fest liegt, wie bestimmte Datentypen verarbeitet werden. Der
> Resourceverbrauch spielt eine Rolle mit. Und nicht zuletzt die interne
> Repräsentation des DB hat entscheidenden Anteil, was aus den Tabellen wird.
>
> Die anderen haben auch das eine oder andere Argument. Letztendlich ist es
> egal
> ob du die Tabelle ORT mit der Spaltenreihenfolge PLZ, ORTSNAME oder
> ORTSNAME,PLZ definierst.
Insgesamt habe ich mich hier bereits überzeugen lassen, dass die
Reihenfolge und Benennung nicht überbewertet werden soll.
Aber ich kann es mir bei Deinem Beispiel nicht verkneifen:
Das Bessere ist der Feind des Guten.
Hier könnte es sein:
Orte
ID (primary key)
PLZ
Name
Oder würdet ihr den Schlüsselkandidat "PLZ" als Primärschlüssel
empfehlen, weil er sozusagen einen sprechenden/natürlichenr Schlüssel
darstellt?
In der wirklichen Welt (in Deutschland), kommt fast überall die
Postleitzahl vor dem Ort.
Konventionen sollte man nicht ohne guten Grund brechen, oder?
Und wenn die Tabelle schon "Ort" heißt, braucht man IMHO diesen
Namensteil nicht mehr im Feldnamen wiederholen.
Einen Plural im Tabellennamen finde ich nützlich. Er zeigt dem
Verwalter (ich rede BTW nicht vom Endanwender, auch oben nicht) auf
intuive Weise an, dass es sich um einen Tabellennamen handelt, wenn er
z.B. in SQL damit hantieren muss.
> btw: Das ist einer der spannendsten Threads in der letzten Zeit.
:)
Andreas
--
OOo 3.1
http://borumat.de/openoffice-writer-tipps
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@de.openoffice.org
For additional commands, e-mail: users-h...@de.openoffice.org
