@shmia:
Ich stimme dir ja zu, dass man das in einer neu anzulegenden Datenbank nicht macht!
Aber hier haben wir anscheinend bereits den Fall, dass eine Datenbank vorhanden ist, die verwendet werden muss. Da lohnt es sich nicht, sich Gedanken über das "Hätte man und "Sollte man" oder das "Hätte man besser nicht" oder "sollte man besser nicht" zu machen.
Hier kommt es darauf an, das konkrete Problem zu lösen.
Ich stimme Dir auch zu, dass man so einen Zustand schafft, der zu einem späteren Zeitpunkt X zum Problem werden kann. Wenn ich das jedoch gegen das jetzige Problem abwäge, so kann ich als Außenstehender keinen qualitativen Unterschied erkennen, was die Maßnahme meiner Ansicht nach grundsätzlich rechtfertigt.
winx hat ja anscheinend nicht den Auftrag, eine Datenbank grundsätzlich auf neue solide füße zu stellen, sondern ein spezielles Problem zu lösen. Wenn dieses Problem ausreichend übersichtlich ist, wird der Kunde sich lieber eine Hand abhacken, als einem kostenintensiven Gesamt-Refactoring der Datenbank zuzustimmen.
Um das Wissen über den ergriffenen Workaround nicht verlorengehen zu lassen bietet sich die Nutzung von ALM-Produkten an. Wer weiß, vielleicht finden wir zwei beide einen Link auf diesen Thread im Konfigurations-Management-System unseres nächsten Arbeitgebers wieder!
MfG
Stefan