Problem beim DB-Design

[Gaert]

Ich habe mitunter den Verdacht, dass das Gehalt von Abap-Entwicklern ein Schmerzensgeld ist ;-)

Da könntest du recht haben

[sticky bit]

Das heißt also, einen natürlichen Schlüssel zugunsten eines künstlichen zu verwerfen, um dann das benötigte Verhalten über Constraints zu rekonstruieren. Umständlich, oder?

Naja, wenn man mal davon absieht, dass in einigen DBMS einfach ein Unique Constraint (und ein NOT NULL) für eine PK deklarierte Spalte erzeugt wird. Also ich finde diese "unnatürliche" Handlung nun nicht so schlimm wie die Probleme die man nachher evtl. bekommen kann...

Abgesehen davon: Dass etwas üblich ist, beweist die Machbarkeit, aber nicht die Sinnhaftigkeit.

Stimmt. Liefert aber auch keinen Gegenbeweis...

Schau dir mal die Tabellen eines SAP-Systems an. Da sind ganz andere Sachen üblich.

Die da wären?

Das ist nun wieder eine Frage der Felddimensionierung und wiederum keine Frage des Datenmodells.

Naja, zumindest wenn man daran arbeitet ein System Umzusetzen, also zu implementieren, zähle ich die Felddimensionierung zum Datenmodell mit dazu. Mag sein, dass das irgendwoanders anders definiert ist. Ändert aber nichts an der Tatsache, das Systeme sich im Laufe ihres Lebens verändern und diese Veränderungen auch Veränderungen an den Feldlängen mit sich ziehen können und das diese Änderungen wahrscheinlicher an konkreten Nutzdatenspalten auftreten als an reinen abstrakten Schlüsselspalten...

[mwanaheri]

Die da wären?

zum Beispiel so Sachen, dass der für Integerzahlen in Abap zu bevorzugende Datentyp N in der zugrundeliegenden Datenbank als char abgelegt wird. Oder dass für fast alle Felder ein eigener Datentyp (mit Bezeichnungsvarianten, ggf Übersetzungen und Ausgabeoptionen) definiert werden sollte, der dann wiederum in einer Tabelle landet.

Naja, zumindest wenn man daran arbeitet ein System Umzusetzen, also zu implementieren, zähle ich die Felddimensionierung zum Datenmodell mit dazu. Mag sein, dass das irgendwoanders anders definiert ist. Ändert aber nichts an der Tatsache, das Systeme sich im Laufe ihres Lebens verändern und diese Veränderungen auch Veränderungen an den Feldlängen mit sich ziehen können und das diese Änderungen wahrscheinlicher an konkreten Nutzdatenspalten auftreten als an reinen abstrakten Schlüsselspalten...

Ein besseres Argument ist eigentlich, dass -- bei geschäftlichen Daten -- eine Datenhaltungspflicht von 10 Jahren besteht und man alle Daten historisieren müsste, wenn man nicht einen einmal vergebenen Usernamen praktisch gesehen nie mehr verwenden können will. Angesichts der relativ geringen Zahl der gut merkbaren Nutzernamen pro Länge ist das eher ein Problem.