# Datenbankdesign



## Zenic (19. Jan 2011)

Hallo!

Zuerst einmal einige Informationen zum aktuellen Status meines Projekts:

aktuell beinhaltet es 3 Tabellen (Objekte =(1:n)=> Kategorien =(1:n)=> Bereiche).
Die Bereiche haben als Attribut eine Bereichsnummer.
Diese Nummer ist innerhalb einer Kategorie eindeutig, kann aber Gesamt gesehen in der Tabelle häufiger vorkommen
Jede Tabelle hat als Primärschlüssel eine ID
die Bereichsnummer kann aktuell NULL sein

Gibt es seitens SQL eine saubere Möglichkeit die Kombination aus 3 Spalten (ID, Kategoriereferenz, Bereichsnummer) einzigartig zu machen? Oder muss ich das beim speichern eines Datensatzes überprüfen und ggf. reagieren?

Ich weiß das, dieser Beitrag vielleicht in einem SQL bzw. DB Forum besser aufgehoben wäre, aber hier bekommt man meist eine sehr schnelle und kompetente Antwort, wodurch ich mich verleiten lies es hier zu posten.

thx


----------



## tfa (19. Jan 2011)

> Gibt es seitens SQL  eine saubere Möglichkeit die Kombination aus 3 Spalten (ID, Kategoriereferenz, Bereichsnummer) einzigartig zu machen? Oder muss ich das beim speichern eines Datensatzes überprüfen und ggf. reagieren?


Du kannst einen unique Index auf diese Spalten anlegen. Eine Überprüfung im Programm vor dem Speichern kannst du zusätzlich aber auch machen.


----------



## DerEisteeTrinker (19. Jan 2011)

tfa hat gesagt.:


> Eine Überprüfung im Programm vor dem Speichern kannst du zusätzlich aber auch machen.



Würde ich als sehr unsauber ansehen. Denn Dinge die die Datenbank von Hause aus mitbringt, brauche ich nicht nochmal implementieren. Wie war das nochmal mit dem Rad?


----------



## tfa (19. Jan 2011)

DerEisteeTrinker hat gesagt.:


> Würde ich als sehr unsauber ansehen. Denn Dinge die die Datenbank von Hause aus mitbringt, brauche ich nicht nochmal implementieren. Wie war das nochmal mit dem Rad?


Die Geschäftslogik gehört ins Programm und nicht in die Datenbank. Wenn der Anwender irgendeine eindeutige Datenkombination angeben muss, dann muss das von deiner Software geprüft werden (am besten hat er gar keine Gelegenheit, es falsch zu machen). Einfach zu sagen "Fragen wir doch mal die DB, was die davon hält" und dann ggf. eine Exception abzufangen und zum Kontrollfluss zu benutzen, finde ich sehr unsauber. 
Es mag Fälle geben, wo man das z.B. aus Performance-Gründen macht, aber die erste Wahl ist das nicht.
Der Index dient nur zur Sicherheit, falls man doch mal einen Bug hat (und natürlich ggf. zur schnelleren Suche).


----------



## Zenic (19. Jan 2011)

Danke erst mal hat funktioniert.

Im Normalbetrieb sollten eigentlich sowieso keine "Fehleingaben" passieren, beim Anlegen der DB und gleichzeitigen Befüllen mit wahllos zusammengeschriebenen Datensätzen, ist mir jedoch dieses Verhalten aufgefallen. Der Index ermöglicht mir jetzt gleiche Dateneinträge definitiv auszuschließen.


----------

