Delphi-PRAXiS
Seite 4 von 6   « Erste     234 56      

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Datenbanken (https://www.delphipraxis.net/15-datenbanken/)
-   -   Datenbankmodellierung (https://www.delphipraxis.net/195991-datenbankmodellierung.html)

mkinzler 13. Apr 2018 14:00

AW: Datenbankmodellierung
 
Der Main_Name ist ja der Name des Parent. Natürlich kann man beides doppelt führen, damit schafft man sich mehr Probleme.

StepByStep 13. Apr 2018 14:11

AW: Datenbankmodellierung
 
Zitat:

Der Main_Name ist ja der Name des Parent. Natürlich kann man beides doppelt führen, damit schafft man sich mehr Probleme.
>> Damit hast du natürlich vollkommen recht... Ich glaube so langsam verstehe ich euch. :)

Jumpy 13. Apr 2018 14:35

AW: Datenbankmodellierung
 
Was man evtl. überlegen könnte hinzuzunehmen wäre dann ein Feld für den Typ oder den Level (im Sinne der Tiefe in einer Baumstruktur). Dies ist nicht zwingend nötig, über die Parents läßt sich das auch ermitteln, aber es erleichtert einem ggf. die Abfragen.

mkinzler 13. Apr 2018 14:40

AW: Datenbankmodellierung
 
Kann aber wieder zu Inkonsistenzen führen.

Jumpy 13. Apr 2018 15:15

AW: Datenbankmodellierung
 
Das ist halt das ewige Dilemma (nicht nur in der IT). Komfort, Bequemlichkeit auf der einen Seite führt zu Risiken, Gefahren auf der anderen Seite. Wenn man so will die Unschärfe-Relation des normalen Lebens gewürzt mit einer Prise Murphy :-D.

mkinzler 13. Apr 2018 15:16

AW: Datenbankmodellierung
 
Deshalb gibt es in diesem Punkt kein richtig oder falsch.

jobo 13. Apr 2018 15:26

AW: Datenbankmodellierung
 
Zitat:

Zitat von mkinzler (Beitrag 1399125)
Kann aber wieder zu Inkonsistenzen führen.

Zitat:

Zitat von Jumpy (Beitrag 1399130)
Das ist halt das ewige Dilemma

Zitat:

Zitat von mkinzler (Beitrag 1399131)
Deshalb gibt es in diesem Punkt kein richtig oder falsch.

Ich würde da sanft widersprechen. Es ist ein Dilemma, ja, besonders für Entwickler, die haarklein die Detailprobleme in den Griff kriegen müssen. Aber es ist auch eine Frage der Prios und letztlich der Entwicklungskosten/Budget.
Inkonsistenzen sind aber kein Schicksal. Man muss darauf achten, dass keine entstehen (haha). Ja klingt banal doof, aber mit Hilfe moderner Datenbanktechnik, Constraints, Triggern, .. kann man das machen. Bei der (bewussten) Entscheidung, etwas denormalisiert zu speichern, muss man die entstehenden Redundanzen eben auch bewusst absichern mit den geeigneten DB Hilfsmitteln. Soviel Zeit (und Geld) muss sein, ist sicher gut investiert.

Codehunter 13. Apr 2018 18:16

AW: Datenbankmodellierung
 
Ich glaube wir haben den/die Threadersteller/in irgendwie erschlagen. Hat sich nicht einmal mehr zu Wort gemeldet :shock:

MyRealName 13. Apr 2018 19:01

AW: Datenbankmodellierung
 
Ich kenne mich mit deutschem accounting nicht aus, aber hier in Kolumbien ist das mit dem Bank-Accounts nur ein Teil der accounts, die man hat. Hier gibt es den PUC (Plan Unico de Cuentas), wo man zu 8-stelligen Account-Nummern Sachen zuordnet, zum Bsp. MwSt noch zu zahlen. Oder offene Rechnungen. Das sind nicht direkt Bank-Accounts, sondern nur identifikatoren um es in Deinem System auseinander zu halten.

Das sieht eher so aus.
Da gibt es dann diverse Vorgaben wie 1 im Title ist immer Activos wie Waren im Lager. 13 in Grupo (Gruppe) sind Schulden, 11 sind Bankkonten. 14 ist das Inventar. Etc.

Codehunter 13. Apr 2018 20:19

AW: Datenbankmodellierung
 
Das würde hier jetzt jeden Rahmen sprengen, die deutsche Buchhaltung zu erklären ^^ Sagen wir mal so: Wo bei euch eine Schraube eingedreht wird, da wird bei uns erstmal eine Maschinenkonstruktionszeichnung für die Maschine zur Schraubenherstellung angefertigt :oops:


Alle Zeitangaben in WEZ +1. Es ist jetzt 09:08 Uhr.
Seite 4 von 6   « Erste     234 56      

Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz