Sinnvoller aufbau einer DB

[stifflersmom]

Zitat:

Zitat von TigerLilly (Beitrag 1428991)

:shock:
Naja, das würde ich schon eher vermeiden.

Ich auch :thumb:

[Beach]

Vielen Dank für diese äußerst konstruktive Kritik.
Werde mich bemühen alles zu beherzigen.

Zitat:

Zitat von TigerLilly (Beitrag 1428983)

[...]
- abhängige Tabellen sollten (für das Datenmodell) keinen eigenen PK brauchen (wt_time_main). Da hat es meist was mit dem Design.

Kannst du mir das bitte etwas näher ausführen? Ich bin leider nicht mehr so Fit in dem ganzen Thema wie ich anfangs noch geglaubt habe und habe hier doch einiges an Lernbedarf. Daher interessiert es mich sehr, was du hiermit meinst.

Zitat:

- Die wt_time_main passt so nicht. Was identifiziert die Tabelle? Kunde+Angestellter+Tag? Ich würde die wt_time_main + Sub zusammenlegen. Das entspricht ja auch viel mehr der Wirklichkeit. Ein MA ist bei Kunde X von/bis und macht was.

Das wirbelt meine Gedanken gerade wieder frisch durcheinander. :?

Aus dem Begriff Kunde sollte besser Projekt werden. Da es beim gleichen Kunde mehrer Projekte geben kann.
In der wt_time_sub gibt es mehrere Einträge die sich auf den gleichen Tag, den gleichen MA und das gleiche Projekt beziehen. Daher nur der Verweis auf die wt_time_main (ist auch ein ungünstiger Name für diese Tabelle.)

Ich bin da Gedanklich wahrscheinlich schon wieder zu weit...

Ich hatte ja geschrieben das ich erstmal nur den monatlichen Stundenreport umsetzen will, aber habe schon die Serviceberichte mit im Hinterkopf.
Da muss ich mir jetzt nochmal Gedanken machen ob ich das alles zusammenpacke oder ob ich hier eher getrennte Bereiche machen will. Wahrscheinlich deutlich einfacher und weniger komplex, aber dafür in gewissen Bereichen Redundant... :freak:

[p80286]

Zitat:

Zitat von TigerLilly (Beitrag 1428983)

- abhängige Tabellen sollten (für das Datenmodell) keinen eigenen PK brauchen (wt_time_main)...
- Die wt_time_main passt so nicht. Was identifiziert die Tabelle? Kunde+Angestellter+Tag? Ich würde die wt_time_main + Sub zusammenlegen. Das entspricht ja auch viel mehr der Wirklichkeit. Ein MA ist bei Kunde X von/bis und macht was.

Da bin ich ganz anderer Meinung. Durch den PK hast Du einen eindeutigen Schlüssel für einen Zeitraum, das kann sinnvoll sein wenn der Zeitraum sich primär auf ein Projekt, Reparatur, Maschine etc. bezieht und nicht nur auf MA.

Weiterhin besteht dann die Möglichkeit über Zeiträume Abfragen zu gestalten. "Was haben wir am 31.02.2056 gemacht?"

Gruß
K-H

[hoika]

Hallo,
ich handhabe das so:
Ein PK hat erst mal nichts mit den Daten der Tabelle zu tun, erst ist also ein artificial key (künstlicher Schlüssel).
Dass kann ein Integer (AutoInc) oder eine GUID sein.

Vorteil:
Der Kunde sagt:
"Das Feld kann nie und nimmer doppelte Werte haben", z.B. Rechnungsnummer -> mein PK

Der Kunde sagt 2 Jahre später
"Die Rechnungsnummer kann jetzt doppelt sein, weil die Standortnummer zusätzlich dazukommt.
Wir nennen das jetzt zusammengesetzte Rechnungsnummer."

Merke:
Glaube keinen Kunden ;)

[Codehunter]

In den meisten Wawi ist die Rechnungsnummer ein Freitextfeld. Dieses wird z.B. über Generatoren und/oder Trigger bei neuen Belegen befüllt. Viele Firmen führen in ihren Rechnungsnummern z.B. auch das Geschäftsjahr. Daher sollte man hier nicht auf die Idee kommen und die Rechnungsnummer durch Schlüsselverkettungen aus verschiedenen Tabellen zu verketten. Denn sobald mal jemand auf die Idee kommt, den Nummernkreis zu ändern ohne das Geschäftsjahr mit zu ändern, hat man genau den Fall der doppelten Belegnummern.

Vielmehr sollte man die in einer Belegtabelle als Freitextfeld anlegen. Auf dieses Feld dann einen Unique-Constraint zu legen kann aber sinnvoll sein. Muss man dann aber auch entsprechend abfangen um im Realbetrieb genau die Fälle abzudecken wo der Anwender Mist baut.

[hoika]

Hallo,
das mit der Rechnungsnummer war nur ein konstruiertes Beispiel.

Mir ging es hier eher darum, dass man als PK wirklich einen künstlichen Schlüssel nimmt,
der mit den eigentlichen Daten nichts zu tun hat.

Sollte ein "richtiges" Feld eindeutig sein müssen, bekommt man das auf DB-Seite locker über einen zusätzlichen Unique-Index hin.

[Codehunter]

Zitat:

Zitat von hoika (Beitrag 1429049)

Hallo,
das mit der Rechnungsnummer war nur ein konstruiertes Beispiel.

Mir ging es hier eher darum, dass man als PK wirklich einen künstlichen Schlüssel nimmt,
der mit den eigentlichen Daten nichts zu tun hat.

Sollte ein "richtiges" Feld eindeutig sein müssen, bekommt man das auf DB-Seite locker über einen zusätzlichen Unique-Index hin.

Weiß ich doch, aber ein gutes Beispiel.

[p80286]

Zitat:

Zitat von Codehunter (Beitrag 1429050)

Zitat:

Zitat von hoika (Beitrag 1429049)

Hallo,
das mit der Rechnungsnummer war nur ein konstruiertes Beispiel.

Mir ging es hier eher darum, dass man als PK wirklich einen künstlichen Schlüssel nimmt,
der mit den eigentlichen Daten nichts zu tun hat.

Sollte ein "richtiges" Feld eindeutig sein müssen, bekommt man das auf DB-Seite locker über einen zusätzlichen Unique-Index hin.

Weiß ich doch, aber ein gutes Beispiel.

Irgendwann legt man sich mit den sprechenden/intelligenten Schlüsseln auf die Nase und dann war das natürlich nicht abzusehen, da eine solche Konstellation nicht abzusehen war:shock:

Gruß
K-H

P.S.
Das gilt auch für die Einsparug des PK in einigen Tabellen.

[hoika]

Hallo,

Zitat:

Irgendwann legt man sich mit den sprechenden/intelligenten Schlüsseln auf die Nase und dann war das natürlich nicht abzusehen, da eine solche Konstellation nicht abzusehen war

Dann gehen die Ausreden los:
"Das war mein Vorgänger."
"Das machen wir immer so."

:)

Zitat:

Das gilt auch für die Einsparung des PK in einigen Tabellen.

???

Platzprobleme auf der Festplatte Connor 170 MB?

[stifflersmom]

Zitat:

Zitat von hoika (Beitrag 1429058)

???

Platzprobleme auf der Festplatte Connor 170 MB?

Großartig!!!
Connor kenne ich auch noch.
Ich weiß noch, wie ich zig 3,5" Disketten in der Hand hatte um Novel Netware auf einem 486 mit 'ner Connor zu installieren...