Datenbankmodellierung

[Asura]

Guten Abend,

ich habe mich mal wieder weiter an mein hobbymäßiges Projekt eines Finanzcheckprogramms gesetzt und weiter an der Datenbankmodellierung gearbeitet.

Ich bin leider was Datenbank angeht noch absoluter Anfänger, weshalb ich mir natürlich nicht zu 100 % sicher sein kann, was

• Unabhängigkeit
• Konsistenz
• Integrität

angeht. Deswegen bitte ich hier einfach mal rüber zu schauen und eventuell Kritik, Verbesserungsvorschläge zu nennen.
Wenn Fragen zur Funktion gewisser Attribute auftreten, werde ich diese hier beantworten.

Würde mich da über eine Überprüfung freuen!

[TigerLilly]

Inhaltlich sage ich nichts, da weiß ich natürlich über dein Projekt zu wenig.Aber allgemein:

Das Password würde ich nicht in der DB speichern, sondern nur den Hash dazu.

Vielleicht wäre es eine Idee, nicht den IBAN abzulegen, sondern noch eine Tabelle Banken zu machen + zu verlinken. Dann kannst du auch den BIC + den Namen der Bank ablegen.

Die Kategorien würde ich eher als Mainkategorien --> Subkategorien --> Kategorien ablegen, aber vielleicht gibt es für deinen Ansatz einen besonderen Grund. Jetzt spießt sich das etwas.

Ich benenne den PK einer Tabelle immer als <Tabellenname>ID, denn heißen die FKs und die PKs gleich. Jedenfalls aber sollten die FKs die referenzierte Tabelle wiedergeben (BankAccountsID vs BankID als FK zu bankaccounts.ID).

Ich bin auch etwas neurotisch, was durchgängige Namensgebung anbelangt: "users" ist Mehrzahl, das ist gut + passend, "senderreceiver" ist Einzahl, das würde ich auch als "senderreceivers" benennen.

Reservierte Bezeichner sind immer problematisch, darum würde ich "Type" nicht nehmen, sondern "TypeFixed", ebenso "Date". Generell bevorzuge ich Bezeichner, die mir sagen, was das Attribut beinhaltet + Type ist sehr nichtssagend. Ich würde auch abgekürzte Bezeichner (Evalu) vermeiden.

HTH :thumb:

[mkinzler]

Der Plural von Receiver ist Receiver

[mjustin]

Für Tabellennamen bevorzuge ich Singular statt Plural. Zum Beispiel "Status" anstatt "Statuses", Category anstatt Categories, unabhängig davon ob die Tabelle einen oder viele Datensätze enthalten kann. Vergleiche AppleBag: auch wenn mehrere Äpfel darin sind, ist es kein ApplesBag. Tabellen sind ähnlich, Container.

Bei der Benennung der Felder würde ich auch an die Erstellung und Wartung des Codes denken und da spielt die eindeutige Benennung eine Rolle. BankAccountsID sowohl in der Tabelle Account als auch in den verknüpften Tabellen wäre bei einer Suche im Sourcecode oder den Datenbankmetadaten nicht so eindeutig wie FKBankAccountsID. Bei Foreignkeys verwende ich FK_TABELLENNAME (anstatt den Namen des PK der referenzierten Tabelle), das ist bei der Suche leichter zu finden.

Über die Pluralbildung von "fixed" könnte man nachdenken :)

[TigerLilly]

Zitat:

Zitat von mkinzler (Beitrag 1399041)

Der Plural von Receiver ist Receiver

https://www.dict.cc/deutsch-englisch...C3%A4nger.html
https://en.wiktionary.org/wiki/receiver

Aber im Grunde ging es mir um die Einheitlichkeit: immer Einzahl oder immer Mehrzahl. beides lässt sich gut argumentieren.

[mkinzler]

https://de.wiktionary.org/wiki/Receiver :?

[TigerLilly]

Zitat:

Zitat von mkinzler (Beitrag 1399044)

https://de.wiktionary.org/wiki/Receiver :?

Die Mehrzahl von "Receiver" in Deutsch(!) ist Receiver, da hast du recht. Die Mehrzahl von "receiver" in Englisch - und das DB-Modell ist in Englisch - ist "Receivers".

[StepByStep]

Moin!

Zum Thema IBAN: Da schließe ich mich TigerLilly in etwa an, aber eine Banktabelle hast du quasi schon mit "bankaccounts". Du hast jetzt zwei Tabellen mit dem Feld "IBAN", was ein wenig Unglücklich hinsichtlich des Themas Redundanz ist. Du könntest du das Feld in "senderreceiver" entfernen, da du es über senderreceiver -> users -> bankaccounts bekommst.

Passwörter IMMER hashen! Niemals als Klartext abspeichern...

Möge man mich korrigieren, aber mMn müsste die "categorie"-Geschichte folgender Maßen sein:

Tabelle "maincategories" = ID, UserID, Name
Tabelle "categories" = ID, BookType, Costtype, MainCatID
Tabelle "subcategories" = ID, UserID, Name, CatgID, MainCatID

Du hast es ja hierarchisch aufgebaut.

Dann nochmal Namensgebung: Wenn du FK-Felder hast, dann kürze sie nicht ab. Aus MainCatID wird dann maincategoriesID beispielsweise. Aber auch Punkte wie Singular - Plural... Ich tendiere da immer zu Singular, auf jeden Fall einheitlich.

Braucht "bookings" keine User-Referenz? Es wäre zudem auch mal hilfreich, wenn man die Beziehungen abgebildet werden, daraus lässt sich auch immmer auf die Sinnhaftigkeit eines DB-Modells schließen. ;-)

Das sind erstmal meine Gedanken dazu.

LG

[Codehunter]

Zitat:

Zitat von mjustin (Beitrag 1399042)

Für Tabellennamen bevorzuge ich Singular statt Plural. Zum Beispiel "Status" anstatt "Statuses", Category anstatt Categories, unabhängig davon ob die Tabelle einen oder viele Datensätze enthalten kann.

Moah wie wahr! Das habe ich bei xtcommerce immer gehasst. Da gibt es Tabellen wie "categories", "products" usw. Und um dem ganzen dann noch die Krone auf zu setzen, gab es Felder wie "categories_id", "products_id" usw.

Bzgl. IBAN: Ich kenne das von diversen WaWi eigentlich genau so, wie hier im DB-Modell auch gelöst: Man hat eine Bankkonten-Referenztabelle, wo die Konten der Kunden hinterlegt sind. Am konkreten Beleg kann man dann aber die IBAN übersteuern. Heißt, das Eingabe-Feld wird aus der Bankkontentabelle vorbelegt, Änderungen des Anwenders aber dann in einem zweiten IBAN-Feld in der Belegtabelle gespeichert. Vielleicht war das ja hier auch so gedacht?

Bzgl. Kategorien: Dafür würde ich nur EINE Tabelle vorsehen und hierarchische Strukturen über zwei Felder "id" und "parent_id" abbilden. Das wiederum ist bei xtcommerce sehr schön gelöst.

[StepByStep]

Zitat:

Vielleicht war das ja hier auch so gedacht?

>> Stimmt, könnte man so natürlich denken. Bei unserem WaWi-Programm, gäbe es dann aber ein Stammdatenformular für Bankverbindungen. Hast du eine andere IBAN wäre das dann ein neuer Satz. Die IBAN ist ja immer eindeutig...

Zitat:

Dafür würde ich nur EINE Tabelle vorsehen und hierarchische Strukturen über zwei Felder "id" und "parent_id" abbilden. Das wiederum ist bei xtcommerce sehr schön gelöst.

>> Ich sage da nur ein Stichwort: Normalisierung.

LG