@jerch: Jetzt verstehe ich was du mit ORM meinst bzw. was ORM eigentlich tut. Du meinst, damit erspare ich mir sämtliche Bibliotheken für SQLite (wobei diese Bibliothek in meinem Python 2.7.6 schon dabei ist), für MySQL, MS SQL, PostgreSQL etc? Ich wäre jetzt dazu übergegangen und hätte für jedes Datenbanksystem eine bestimmte Bibliothek geladen und dementsprechend gearbeitet. Ich werde mich dazu einlesen müssen.
Und wieso ich für jede Kategorie eine Datenbank erstelle? Eben weil die Bücher ganz andere Angaben haben als zum Beispiel Filme oder anders als ein Adressbuch. Worüber ich jedenfalls nachdenke, ist, dass ich eine weitere Datenbank anlege, in der sozusagen Stammdaten reinkommen. Zum Beispiel Personen. Und dass dann von dort aus "Beziehungen" zu anderen Datenbanken hergestellt werden und die Personen nicht redundant vorkommen. Sonst habe ich nachher die gleichen Personen einmal in der Bücher-Datenbank, Musik-Datenbank und Film-Datenbank. Aber ich glaube, davon hast du mir ja abgeraten. Und das mit der Itemtyp-Ebene erscheint für mich nicht befriedigend, da man dabei nicht so stark normalisieren kann.
Mit comboBox eine entsprechende Funktion aufrufen
Das ist doch kein Grund für eine andere Datenbank. Das ist eher ein Grund für separate Tabellen, wie ich vorgeschlagen hatte, wenn man nicht übermässig normalisieren möchte. Eine Datenbank kommt sehr gut mit vielen verschiedenen Tabellen klar.Sophus hat geschrieben:Und wieso ich für jede Kategorie eine Datenbank erstelle? Eben weil die Bücher ganz andere Angaben haben als zum Beispiel Filme oder anders als ein Adressbuch.
@jerch: Ich bin leider noch nicht so sehr erfahren mit Datenbanken. Aber wie es bis jetzt ist mag ich es irgendwie. Es wirkt "aufgeräumter". Mit dem Verfahren bestimmte Attributsets in eine Tabelle zu pressen wirkt bestimmt sehr unaufgeräumt, und die Redundanz ist bestimmt sehr groß. Wenn ich dich also richtig verstehe, dann soll ich die Bücher und all die anderen Kategorien auch in die selbe Datenbank stecken, wo auch die Film-Kategorie ist?
@Sirius3: Stimmt, hattest du erwähnt. Aber nur so aus Neugier. Welche Nachteile erkaufe ich mir, wenn ich für jede Kategorie eine Datenbank anlege? Sagen wir mal eine Datenbank für Filme, Musik, Bücher und dann eine Datenbank wo alle Stammdaten vorhanden sind. Zum Beispiel Länder, Personen, Orte, Genre etc. Die Redundanz wäre damit aufgehoben, richtig?
@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.
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.
@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.