Hallo Andreas, Am Montag, 15. Juni 2009 schrieb Andreas Borutta: snip > > <exkurs> Syntax für Instrumentierung > </exkurs> Du siehst hier an diesem Beispiel schon, dass ein durchdachter Entwurf das A und O ist. Solche Sache wie zB das mit den Saxophonen, die extra aufgeführt werden und nicht ins Konzept passen, dürfen bei einem Datenbankentwurf nicht passieren.
> > > snip > > > >> 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. btw: Das ist einer der spannendsten Threads in der letzten Zeit. -- Mit freundlichen Grüßen Matthias Müller (Benutzer #439779 im Linux-Counter http://counter.li.org) PS: Bitte senden Sie als Antwort auf meine E-Mails reine Text-Nachrichten!
signature.asc
Description: This is a digitally signed message part.
