Ich glaube wir haben den/die Threadersteller/in irgendwie erschlagen. Hat sich nicht einmal mehr zu Wort gemeldet
So ungefähr !
Ich wollte mir Zeit nehmen, um alles mir durchzulesen und zu kommentieren! Aber mit der Diskussion bin ich eindeutig überfordert
Ich mach mich mal an die Arbeit und versuche mal die Hilfen zu Kommentieren bzw. mit weiteren Fragen zu füttern!
Das Password würde ich nicht in der
DB speichern, sondern nur den Hash dazu.
Das hatte ich tatsächlich vor, ich wollte über MD5 oder SHA1 nach der Erstellung des Benutzerkontos den Hash im Programm selber erstellen und diesen dann auf der Datenbank abspeichern lassen. Beim Login würde ich dann wieder das Passwort als Hash erstellen und diesen mit dem hinterlegten Hash vergleichen.
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.
Was wäre anhand dessen der Vorteil? Gut ich sehe sowieso ein für mein Vorhaben ist die IBAN nicht notwendig. Meine Intention war dahinter, dass ich eine Art Adressbuch erstelle anhand dessen man später die Buchungen an Personen zuweisen kann. Also die IBAN wäre für die Funktion nicht notwendig.
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.
In den Kategorien sehe ich selber auch noch das größte Problem in der Modellierung.
Ich versuche mal meine Intention hinter dem aktuellen Aufbau zu erläutern:
- Attribut Costtype ist für mich die Unterscheidung von Fixen und variablen Kosten.
Diese werden dann in der Tabelle Bookings zugewiesen. Die Tabelle fixed (Fixe Kosten) sollte für das Programm eine Hilfestellung sein, um die Fixe Kosten immer wieder neu in der Tabelle Bookings zu verbuchen und gleichzeitig dem Benutzer eine Möglichkeit zu bieten hier einen Überblick über die Fixe Kosten zu haben und diese leicht abändern zu können.
- Attribut Booktype ist dafür da einfach über ein Boolean Wert festzustellen: Ist dies eine Minusbuchung oder Plusbuchung. Gut ich könnte das auch einfach anhand der Zahl (Amount aus Tabelle Booking) ermitteln, die ja entweder ein Minus oder kein Minus hat. Wäre eventuell auch eine bessere Lösung.
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).
Nur damit ich das verstanden habe als Beispiel:
In der Tabelle bankaccounts wäre dann mit deinem Verfahren es nicht UserID sondern Users.ID bzw. UsersID?
Sprich der FK hat immer den Namen der referenzierten Tabelle als (ich nenne es mal) Pre Klausel?
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.
Gut, das werde ich ändern, damit kommen wir wohl auch zu einem Großen Thema: Mehrzahl oder Nicht:
Es wird vllt hier ein paar schmerzen, aber ich finde zum Teil ist der Plural für mich Sinnhaft. Ich kann die Argumentation absolut nachvollziehen. Ich kann aber anhand des Plurals für mich schon direkt festlegen: Das ist eine Tabelle und kein Attribut und es liest und schreibt sich für mich später bei der Erstellung einfach besser, wenn ich den Plural benutze. Kann dies schwer erklären wieso das der Fall ist.
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.
Ja da hast du Recht. Meine Intention war dahinter als Beispiel:
Maincategorie: Verpflegung das umschließt die Subcategorien: Nahrung, Getränke, Tabak etc.
Sprich ich kann später bei der statistischen Auswertung meiner Kontodaten mir anhand von Masken/Filter Eingaben die Ergebnisse anzeigen, die mich wirklich interessieren. Beispiel: Wie viel gebe ich im Monat nur für Nahrung aus, wie viel für Getränke etc.
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.
Habe ich deswegen nicht gemacht, da ein User mehrere Bankaccounts haben kann und ein Bankaccount mehrere Buchungen. Sprich in der Buchung an sich ist ja schon die UserID anhand der BankAccountID hinterlegt. So dachte ich mir das.
Des Weiteren wundere ich mich, dass du nach den Beziehungen fragst, da die doch in der Grafik abgebildet sind anhand den Verbindungen. Der Senkrechte Strich bedeutet eine 1 und der umgedrehte Pfeil das n. Sprich: 1:n Beziehungen habe ich dort gekennzeichnet.
Zu der fortgefolgten Diskussion kann ich mich nicht zu äußern, da ich wirklich nur ein Anfänger in Sachen Datenbanken bin. Also wenn hier, vor dem Hintergrund meiner Erklärung zu den Kategorien (siehe erste Kommentierung zu der Antwort von StepByStep), mir ein passendere Modelllösung vorgeschlagen wird mit einer kleinen Erklärung weshalb, dann würde mir das sehr viel mehr helfen.
Ich denke weitere Kategorisierungsmaßnahmen würden auch nicht hinzukommen da zwei Kategorien zur Gliederung eines Buchungseintrages ausreichen, um seine Funktion wiederzuspiegeln.
Ich bitte vllt auch noch mal die Lösung mit Evalution näher zu begutachten.
Mein Vorhaben ist hier, dass pro Bankaccount ein Bewertungssystem vergeben wird (Sprich ein Benutzer kann mehrere besitzen). Bewertungssystem sehe ich mit einer persönlichen Einschätzung über die Notwendigkeit der Buchung. Das lässt später wieder in statistischen Auswertungen heran ziehen, indem mir das Programm sagt: 25% deiner Kosten sind nach deinem Bewertungsschema wirklich notwendig (zum Beispiel 1 = sehr notwendig, 6 = unnötig / Luxus).
So lässt sich leicht herausstellen: Wo habe hohe Ausgaben und wie werden diese bewertet. Im vorangegangen Beispiel: Wie notwendig sind diese Ausgaben.
//Edit
Ergänzend zu dem Kategorien will ich diese natürlich dem Nutzer überlassen, diese frei einzustellen und zu bearbeiten.
In Verbindung mit dem Bewertungssystem kann man darüber auch nachdenken statt die Buchung als einzelnes zu bewerten mit dem Benotungssystem, eher vllt die Kategorien zu bewerten.
Ein Problem sehe ich auch noch, was passiert wenn Kategorien gelöscht oder ersetzt werden. Da die Buchung ja Kategorien zugeordnet ist.