Sinnvoller aufbau einer DB

**Sherlock**

Es gibt auch in RDBMS Datumstypen, warum etwas anderes verwenden? Das macht es doch nur unnötig komplex.
Und warum schon von vorneherein einen DB-Switch einplanen, wenn man gleich auf die End-DB setzen kann?

Sherlock

**haentschman**

Moin...

Zitat:

"personal_number" INTEGER,

Die Personalnummer hat in dieser Tabelle nichts zu suchen. Besser ein Schlüssel auf die Mitarbeitertabelle (z.B. ID_Employee)

**Beach**

Zitat von haentschman:

Moin...

Zitat:

"personal_number" INTEGER,

Die Personalnummer hat in dieser Tabelle nichts zu suchen. Besser ein Schlüssel auf die Mitarbeitertabelle (z.B. ID_Employee)

Die Personalnummer ist in dem Fall als Querverweis auf die Mitarbeitertabelle gedacht. Da diese eindeutig und dauerhaft einem MA zugeordnet ist.
Welchen direkten Vorteil hätte die Verwendung der ID anstelle der PersNR?

**stifflersmom**

Zitat von Beach:

Zitat von haentschman:

Moin...

Zitat:

"personal_number" INTEGER,

Die Personalnummer hat in dieser Tabelle nichts zu suchen. Besser ein Schlüssel auf die Mitarbeitertabelle (z.B. ID_Employee)

Die Personalnummer ist in dem Fall als Querverweis auf die Mitarbeitertabelle gedacht. Da diese eindeutig und dauerhaft einem MA zugeordnet ist.
Welchen direkten Vorteil hätte die Verwendung der ID anstelle der PersNR?

Eine Personalnummer "könnte" sich ändern durch Umfirmierung oder Ähnliches. Die ID in einer Tabelle normalerweise nicht

**mkinzler**

Die Tabelle ist auch recht unnormalisiert.

ich würde die ganzen Zeitspannen in eine Untertabelle ablegen.

**Beach**

@stifflersmom: Gutes Argument.

@mkinzler: Genau das ist der Grund warum ich nachfrage...
Kannst du das etwas näher aufschlüsseln wie du es machen würdest?

In einer Untertabelle einfach nur Anfangs und Endzeit (egal ob als Reise- oder Arbeitszeit) und das dann per ID-Verweis in der Haupttabelle entsprechend zuordnen für was?

**haentschman**

Moin...

Zitat:

Die Personalnummer ist in dem Fall als Querverweis auf die Mitarbeitertabelle gedacht. Da diese eindeutig und dauerhaft einem MA zugeordnet ist.

Da hat mit Sicherheit die DSGVO was dagegen.

Sinnvoller aufbau einer DB

AW: Sinnvoller aufbau einer DB

AW: Sinnvoller aufbau einer DB

AW: Sinnvoller aufbau einer DB

AW: Sinnvoller aufbau einer DB

AW: Sinnvoller aufbau einer DB

AW: Sinnvoller aufbau einer DB

AW: Sinnvoller aufbau einer DB

Forumregeln

Sherlock Registriert seit: 10. Jan 2006 Ort: Offenbach 3.811 Beiträge Delphi 12 Athens	#1 AW: Sinnvoller aufbau einer DB 26. Mär 2019, 10:52 Es gibt auch in RDBMS Datumstypen, warum etwas anderes verwenden? Das macht es doch nur unnötig komplex. Und warum schon von vorneherein einen DB-Switch einplanen, wenn man gleich auf die End-DB setzen kann? Sherlock Oliver Geändert von Sherlock (Morgen um 16:78 Uhr) Grund: Weil ich es kann
	Zitat

haentschman Online Registriert seit: 24. Okt 2006 Ort: Seifhennersdorf / Sachsen 5.436 Beiträge Delphi 12 Athens	#2 AW: Sinnvoller aufbau einer DB 26. Mär 2019, 10:55 Moin... Zitat: "personal_number" INTEGER, Die Personalnummer hat in dieser Tabelle nichts zu suchen. Besser ein Schlüssel auf die Mitarbeitertabelle (z.B. ID_Employee)
	Zitat

mkinzler (Moderator) Registriert seit: 9. Dez 2005 Ort: Heilbronn 39.874 Beiträge Delphi 11 Alexandria	#5 AW: Sinnvoller aufbau einer DB 26. Mär 2019, 11:21 Die Tabelle ist auch recht unnormalisiert. ich würde die ganzen Zeitspannen in eine Untertabelle ablegen. Markus Kinzler
	Zitat

haentschman Online Registriert seit: 24. Okt 2006 Ort: Seifhennersdorf / Sachsen 5.436 Beiträge Delphi 12 Athens	#7 AW: Sinnvoller aufbau einer DB 26. Mär 2019, 11:52 Moin... Zitat: Die Personalnummer ist in dem Fall als Querverweis auf die Mitarbeitertabelle gedacht. Da diese eindeutig und dauerhaft einem MA zugeordnet ist. Da hat mit Sicherheit die DSGVO was dagegen.
	Zitat