AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren

Datenbankmodellierung

Ein Thema von Asura · begonnen am 12. Apr 2018 · letzter Beitrag vom 16. Apr 2018
Antwort Antwort
Seite 3 von 6     123 45     Letzte » 
StepByStep

Registriert seit: 12. Nov 2014
Ort: Schleswig-Holstein
61 Beiträge
 
Delphi 7 Professional
 
#21

AW: Datenbankmodellierung

  Alt 13. Apr 2018, 12:19
Das ist wohl richtig, aber das sind im Regelfall doch auch Daten, die sich eben nicht weiter Normalisieren lassen.
Jan
  Mit Zitat antworten Zitat
mkinzler
(Moderator)

Registriert seit: 9. Dez 2005
Ort: Heilbronn
38.962 Beiträge
 
Delphi 10.2 Tokyo Enterprise
 
#22

AW: Datenbankmodellierung

  Alt 13. Apr 2018, 12:27
Wenn Du mehrere Tabellen für das gleiche anlegst würde ich auch nicht von Normalisierung reden. Kaetegorien sind Kategorien, ob sie nun Haupt- oder Unterkategorien sind.
Markus Kinzler
  Mit Zitat antworten Zitat
StepByStep

Registriert seit: 12. Nov 2014
Ort: Schleswig-Holstein
61 Beiträge
 
Delphi 7 Professional
 
#23

AW: Datenbankmodellierung

  Alt 13. Apr 2018, 12:31
Ich hatte auch mehr etwas im Kopf wie: Auftrag (Hauptkategorie), Auftragsposition (Kategorie), Auftragsunterposition (Unterkategorie). So wäre es nach seinem Beispiel, zumindest für mich.
Jan
  Mit Zitat antworten Zitat
mkinzler
(Moderator)

Registriert seit: 9. Dez 2005
Ort: Heilbronn
38.962 Beiträge
 
Delphi 10.2 Tokyo Enterprise
 
#24

AW: Datenbankmodellierung

  Alt 13. Apr 2018, 12:43
Auftragspositionen und Auftragsunterpositionen sind eigentlich das gleiche, der Fremdschlüssel steuert dies ja.
Aufträge sind natürlich etwas komplett anderes.

Ich würde eher eine Tabelle für Aufträge, Lieferscheine, Rechnungen usw. verwenden und eine für die Positionen.
Markus Kinzler
  Mit Zitat antworten Zitat
StepByStep

Registriert seit: 12. Nov 2014
Ort: Schleswig-Holstein
61 Beiträge
 
Delphi 7 Professional
 
#25

AW: Datenbankmodellierung

  Alt 13. Apr 2018, 12:55
Hm... ich finde den Ansatz wirklich interessant. Nun kenne ich auch noch nicht so viele... Bei uns haben wir das alles ausgelagert in eigene Tabellen, um eben alles zu trennen. Käme alles in eine Tabelle würdest du dann einen Typen einfügen? Muss ja, sonst kann man das nicht unterscheiden, um was für einen Belegtypen es sich handelt. Und darauf dann einen Index... Klar geht das, aber habe noch nicht so ganz verstanden warum? Was macht das "besser" als es zu trennen, bzw. zu normalisieren?

Aber wir driften auch weiter vom Ursprungsthema ab.

LG
Jan
  Mit Zitat antworten Zitat
jobo

Registriert seit: 29. Nov 2010
2.308 Beiträge
 
Delphi 2010 Enterprise
 
#26

AW: Datenbankmodellierung

  Alt 13. Apr 2018, 13:15
Aber wir driften auch weiter vom Ursprungsthema ab.
Bei einer Modellierungsfrage finde ich die Diskussion hier nicht wirklich abgedriftet.
Und das Modell des TE finde ich bezüglich der Kategorien nicht sehr klar.

Ich sehe das so wie mkinzler und codehunter, ein Parentverweis für eine hierarchische Kategorisierung ist idR naheliegend und kein Normalformverstoß. Selbst wenn er das wäre, sowas wäre auch nicht selten und m.E. nicht per se strafbar. Frage wäre immer, welche Vor und Nachteile aus bestimmten Verfahren entstehen.
10 Tabellen für verschiedene Ebenen halte ich dagegen schon für fragwürdig.
Wer oder was auch immer einen solchen Kategorieverweis bei sich trägt, ist per Model darauf festgenagelt. Also quasi wie in einem Kastensystem, frühstens nach Tod und Wiedergeburt gibt's einen anderen Level. Nicht sehr flexibel.

Was die Performanceaspekte angeht:
Performanceprobleme kann es immer geben, natürlich gern wenn Tabellen sehr groß werden. In solchen Fällen kann man über Denormalisierung nachdenken, aber immer zuletzt. Gute Indizierung, geeignete Datenbanken mit smarter Implementierung und intelligenter Abfragesyntax wären da für mich naheliegender.
Gruß, Jo
  Mit Zitat antworten Zitat
StepByStep

Registriert seit: 12. Nov 2014
Ort: Schleswig-Holstein
61 Beiträge
 
Delphi 7 Professional
 
#27

AW: Datenbankmodellierung

  Alt 13. Apr 2018, 13:36
Zitat:
Und das Modell des TE finde ich bezüglich der Kategorien nicht sehr klar.
>> Das finde ich auch, je mehr ich darüber nachdenke.

Ich stehe momentan wirklich auf dem Schlauch... Es ist mir erklärlich, weshalb ich alles in eine Tabelle packen sollte. Die würde dann ja irgendwie so aussehen:

Kategorie
ID
BookType
Costtype
Sub_Name
Main_Name
Parent
Child

Sowohl Parent als auch Child würden dann NULL-Werte enthalten, was für Abfragen doch absolut unsinnig wäre. Man bräuchte dann ja mindestens noch einen Typen um festzulegen ob es eine Main-, Kategorie oder Subkategorie ist. Dann würde es wieder gehen... Aber hübsch ist das doch niemals.

LG
Jan
  Mit Zitat antworten Zitat
mkinzler
(Moderator)

Registriert seit: 9. Dez 2005
Ort: Heilbronn
38.962 Beiträge
 
Delphi 10.2 Tokyo Enterprise
 
#28

AW: Datenbankmodellierung

  Alt 13. Apr 2018, 13:41
Zitat:
Käme alles in eine Tabelle würdest du dann einen Typen einfügen? Muss ja, sonst kann man das nicht unterscheiden, um was für einen Belegtypen es sich handelt.
Eigene Tabelle und FK in Tabelle für die Belege.
Zitat:
Was macht das "besser" als es zu trennen, bzw. zu normalisieren?
Es ist flexibler.

Und Warum sollte eine System mit den Tabellen
'Order', 'DeliveryNote', 'Invoice', ..., 'OrderPosition', 'DeliveryPosition', 'InvoicePosition', ...

normalisierter sein als ein System mit den Tabellen 'ReceiptType', 'Receipe', 'Position'?

Wenn jetzt später ein neuer Belegtyp z.B. Bearbeitungslaufzettel benötigt wird musst du im 1. Fall das komplette Modell erweitern und auch das Programm anpassen; im 2. Fall wird einfach ein neuer Datensatz in 'ReceiptType' eingefügt.
Markus Kinzler
  Mit Zitat antworten Zitat
mkinzler
(Moderator)

Registriert seit: 9. Dez 2005
Ort: Heilbronn
38.962 Beiträge
 
Delphi 10.2 Tokyo Enterprise
 
#29

AW: Datenbankmodellierung

  Alt 13. Apr 2018, 13:46
Zitat:
Und das Modell des TE finde ich bezüglich der Kategorien nicht sehr klar.
Kategorie
ID
BookType
Costtype
Sub_Name
Main_Name
Parent
Child

Sowohl Parent als auch Child würden dann NULL-Werte enthalten, was für Abfragen doch absolut unsinnig wäre. Man bräuchte dann ja mindestens noch einen Typen um festzulegen ob es eine Main-, Kategorie oder Subkategorie ist. Dann würde es wieder gehen... Aber hübsch ist das doch niemals.

LG
"Main_Name" und "Child" sind in diesem Fall überhaupt nicht notwendig, da redundant. "Sub_name" besser "Name".
Markus Kinzler
  Mit Zitat antworten Zitat
StepByStep

Registriert seit: 12. Nov 2014
Ort: Schleswig-Holstein
61 Beiträge
 
Delphi 7 Professional
 
#30

AW: Datenbankmodellierung

  Alt 13. Apr 2018, 13:56
Zitat:
Wenn jetzt später ein neuer Belegtyp z.B. Bearbeitungslaufzettel benötigt wird musst du im 1. Fall das komplette Modell erweitern und auch das Programm anpassen; im 2. Fall wird einfach ein neuer Datensatz in 'ReceiptType' eingefügt.
>> Das ist mir schon klar. Beide Varianten gehen, die Wartbarkeit der Ersten ist natürlich höher, aber dafür hat man keine aufgeblähten Tabellen. Ich glaube das ist eine persönlich Ansicht darauf: Entweder höherer Wartungsaufwand und schlankere Tabellen oder eben andersrum. Kann das sein? Einen anderen signifikanten Unterschied gibt es ja nicht, bis auf eventuell noch Performance.

Zitat:
"Main_Name" und "Child" sind in diesem Fall überhaupt nicht notwendig, da redundant. "Sub_name" besser "Name".
>> Aber ich lege doch alle drei Kategorietabellen übereinander und da es einen Namen in Sub und Main gibt, brauche ich beide doch wieder. Andernfalls würde es ja bedeuten, dass eine der beiden Tabellen entfällt. Und warum will ich kein Child? Innerhalb dieser drei Ebenen muss ich doch auch zurück referenzieren können.

LG
Jan
  Mit Zitat antworten Zitat
Themen-Optionen Thema durchsuchen
Thema durchsuchen:

Erweiterte Suche
Ansicht

Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 20:36 Uhr.
Powered by vBulletin® Copyright ©2000 - 2018, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2018 by Daniel R. Wolf