@Sophus:
Ich bin mir nicht sicher, ob wir das gleiche unter den Begriffen Datenbank, Normalisieren und Redundanz verstehen.
Deine Frage nach getrennten Datenbanken ist vergleichbar mit der Frage, warum beim Auto normalerweise ein Kofferaum eingebaut ist. Den Raum könnte man sparen und wers brauchts, nimmt einen Anhänger. Aber nein, der Kofferaum ist dran, weil wir Autos als Transportvehikel verstehen und zusätzlicher Stauraum sinnvoll ist - Transport und Auto sind für uns verknüpft.
Auf Deine Datenbanksituation übertragen - die Daten stehen in Relation zueinander, ein gibt einen Zusammenhang. Z.B. kann ein Buchautor kann auch als Koautoren, Regisseur etc. bei einem Film mit wirken. D.h. es gibt mögliche Verknüpfungen zwischen Filmen und Bücher z.B. über einen Autor. Eine relationale Datenbank versucht das mit Relationen abzubilden bei möglichst kleiner Redundanz. Dein Multi-DB-Ansatz ist genau das Gegenteil mit zusätzlichem Informationsverlust - der Autor müsste zweimal gespeichert werden (redundant) und du müsstest zusätzlich eine externe Konsistenzbedingung einführen, um nicht die Information zu verlieren, dass es sich um ein und dieselbe Person handelt.
Mit comboBox eine entsprechende Funktion aufrufen
@jerch: Danke. Ok. Was für mich nur noch "offen" bleibt, ist deine Ansicht von Itemtypen-Ebene. Du hast es zwar schon paar mal beschrieben, dass bestimmte Attribute zusammen gezogen werden können. Aber wenn ich mein derzeitige Bild anschaue, was ich euch hier zur Verfügung gestellt habe, frage ich mich, was du da "zusammenführen" würdest.
Mit Itemtypen meinte ich Bild, Film, Buch etc. - in Datenbanksprech Entitätstypen. Es gibt simple Regeln, wie man von realen Daten zu einem datenbanktauglichen Schema kommt - siehe z.B. https://www.hdm-stuttgart.de/~riekert/l ... /chap4.htm
Da ich nichts von Deinen Daten bisher gesehen habe, dann ich Dir nicht sagen, was ich wie zusammenführen würde.
Da ich nichts von Deinen Daten bisher gesehen habe, dann ich Dir nicht sagen, was ich wie zusammenführen würde.