Design / Namens - Richtlinien

Alles was sonst nirgends rein passt.
Antworten
marco scheuble
Neuer Benutzer
Beiträge: 3
Registriert: Fr 8. Aug 2014, 08:20

Design / Namens - Richtlinien

Beitrag von marco scheuble » Di 2. Dez 2014, 13:55

Hallo Zusammen,

wir diskutieren in unserer Firma gerade die Möglichkeit DB-Richtlinien aufzustellen. Es geht dabei um so Dinge wie:
- Benennung
- Trigger verwenden ( ja, nein )
- On Cascade Delete verwenden ( ja, nein )
- LUT Design
...

Da ich im Internet nicht wirklich schlau werde, wollte ich fragen, ob mir hier jemand diesbezüglich Tips geben kann.
Gibt es irgendwelche Richtlinien?
Oder was ist Eure Meinung zu den angesprochenen Punkten?

Gruss, Marco

Gisman
Erfahrener Benutzer
Beiträge: 1115
Registriert: Fr 20. Jan 2006, 15:30
Wohnort: Pfalz
Kontaktdaten:

Re: Design / Namens - Richtlinien

Beitrag von Gisman » Di 2. Dez 2014, 16:52

Also ich mach das so (zumindest versuche ich es durchzuhalten):

Benennung

Schema: Typ_Objekt[_Ergänzung]
-Typ ist je nachdem v=View, mv=materialized view, t = Table, Ergänzung=vielsagender text
-Felderbezeichnungen vielsagende Namen
-Join-Tabellen haben keinen Typ und fangen mit join_an und enthalten die beiden gejointen Tabellennamen

Sprache je nach Adressat Deutsch/Englisch, wobei mir Englisch lieber ist. Eigenen Code schreib ich immer klein, Funktionen etc. bekommen vielsagende Namen und eventuel einen Präfix, der das Anwendungsfeld beschreibt (Beispiel PostGIS ST_ = SpatialTemporal...)

Trigger
Ja. Wenn sinnvoll. Natürlich nicht in Tabellen wo schnell viel Zeug rein muß.

on delete cascade
Ja. wenn sinnvoll. Ist mir jedenfalls lieber, als wenn ich mir jeden Fusel im Datenmodell selbst suchen muß zum Löschen. Manchmal setze ich aber auch per Trigger einen Marker is_deleted oder is_valid, manchmal möchte man ja Dinge behalten, aber trotzdem vom Auswerten ausschliessen.

LUT-Design
???

Gruß Uwe

Antworten