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