Das deutsche Python-Forum

Hallo, ich schon wieder,

mein erstens Python/PySide-Projekt wächst und gedeiht und ich bin immer noch glücklich über meine Entscheidung, das ganze in Python zu machen. Auch mit der SQLite-Datenbank habe ich nun schon den ersten Teil einigermassen hinbekommen, obwohl mir die Sache mit SQL immer noch teilweise recht "mystisch" vorkommt, weil z.B. die Fehlermeldung nicht sonderlich aufschlussreich sind.

Jetzt habe ich folgendes Problem, an dem ich jetzt schon tagelang knabbere und nicht weiterkomme. Ich habe zwei dictionarys in meiner Datenstruktur, die ich nun auch gerne in die Datenbank bringen möchte. Die sehen in etwa so aus: Als DB-Datentypen dachte ich erst mal an string. Und natürlich würde ich die dicts auch irgendwie wieder zurückbekommen.

Wie kann man das in Python hinbekommen ? Für einen Tip wäre ich Euch echt dankbar, weil ich schon fast die Lust vor Frust verliere.
Oder sollte ich vielleicht doch besser ein array statt einem dict nehmen.

mephisto-online hat geschrieben:mein erstens Python/PySide-Projekt wächst und gedeiht und ich bin immer noch glücklich über meine Entscheidung, das ganze in Python zu machen.

Und dabei hat dein aktuelles Problem gar nichts mit Python zu tun, sondern ganz generell mit relationalen Datenbanken

Du musst mehr in Datenstrukturen denken, dann ist das Problem einfacher zu lösen. Wenn du ein Dictionary abbilden möchtest, dass musst du dir als erstes die ganz entscheidende Frage stellen: Was ist eigentlich ein Dictionary? Die Frage hast du sicher schnell beantwortet: es handelt sich dabei um eine eine injektive Abbildung von einem eindeutigen Schlüssel in einen beliebigen Wert. Und genau so musst du es in SQL auch umsetzen. Eine Spalte für den Schlüssel, welcher UNIQUE sein muss, und eine Spalte für den Wert. Unter Umständen noch eine Spalte für eine eindeutige ID. Das hängt aber von der spätern Anwendung ab, ob die Spalte sinnvoll ist.

mephisto-online hat geschrieben:Als DB-Datentypen dachte ich erst mal an string. Und natürlich würde ich die dicts auch irgendwie wieder zurückbekommen.

Verwende keine Strings um strukturierte Daten zu halten, wenn das nicht wirklich notwendig ist. Suchen darauf sind schwierig, umständlich und teuer. Im schlimmsten Fall musst du alle Daten abfragen, parsen und auswerten. Dann kannst du den Umweg über die Datenbank aber auch gleich sein lassen.

Auch hier musst du dir wieder die Frage stellen: Was ist eine Liste? Es handelt sich um eine geordnete Menge von Elementen. Wir nehmen einfach mal an, dass alle Elemente in der Liste den selben Typ haben. Das *geordnet* ist ein eindeutiger Hinweis auf einen Index und bei dem Element handelt es sich wieder um einen Wert. Eine Tabelle für *eine* Liste braucht also einen Index und ein Wert. Da du beliebig viele Listen in einer Tabelle speichern willst, braucht jede Liste noch eine ID.

Das ganze musst du jetzt nur noch zusammenfügen:
Falls du natürlich eine konstante Anzahl an Elementen in den Listen haben solltest, dann kannst du aus der einen value-Spalte im Dictionary natürlich auch mehrere Spalten für die Werte machen und die Listentabelle auslassen.

Wie kann man das in Python hinbekommen ? Für einen Tip wäre ich Euch echt dankbar, weil ich schon fast die Lust vor Frust verliere.
Oder sollte ich vielleicht doch besser ein array statt einem dict nehmen.[/quote]

Edit: Das Tupel aus list_id und index sollte natürlich noch UNIQUE sein. Und beim Löschen von Elementen aus den Listen ist Vorsicht geboten. Unter Umständen bietet sich auch eine ungeordnete Menge an, ich kenne dein Szenario nicht.

Das ist ja mal eine ausführliche Antwort. Vor ein paar Minuten habe ich es dann nun doch erst mal hinbekommen. Ich habe die dicts mit simplejson serialisiert und es klappt. Das hatte vorher aber alles nicht geklappt, weil ich den Fehler in meinem Programm gesucht hatte aber eine der 33 Spalten in der DB falsch definiert war und ich dauernd einen “Parameter count mismatch”-Fehler bekommen hatte. Zu blöd ! Aber seinen eigenen Fehler findet man nun mal besonders schlecht ...

Aber Dein Einwand ist richtig bezüglich der Suchbarkeit. Bei genauerem Nachdenken könnte es irgendwann ja doch mal interessant sein, auch nach einem der Einzelwerte suchen zu können. So muss ich für jeden record erst "auspacken", um vergleichen zu können. Ansonsten brauche ich diese dicts ja nur als Ganzes.

Aber da Du ja auch geschrieben hast, dass das wohl kein Python-Problem ist, erkläre ich jetzt meine Frage mal als erledigt.

@mephisto-online: Dein Datenbankmodel hat ein echtes Problem, wenn Du 33 Spalten hast. Das kann kein Mensch mehr sinnvoll überblicken. Wenn Du ein ORM benutzt, sollte ein Parameter-count-mismatch aber auch nicht auftreten. Wenn nicht jedes Arrayelement eine dezidierte Eigenschaft hat, würde ich vom Ausrollen von Listen in Tabellenspalten abraten. Fragen wie, Suchen nach dem größten Element, oder sortieren nach dem Mittelwert, etc. lassen sich damit nur viel umständlicher Lösen.

Vielleicht könnte man das Problem mal anders herum angehen: was genau hast du mit den Wörterbüchern und Listen überhaupt vor? Vielleicht ist eine Datenbank einfach der falsche Container. Wie Sirius schon schrieb, kann dass Ausrollen unter Umständen ganz schön nervig werden.

mephisto-online hat geschrieben:Aber da Du ja auch geschrieben hast, dass das wohl kein Python-Problem ist, erkläre ich jetzt meine Frage mal als erledigt.

So war das nicht gemeint. Du kannst hier auch weiterhin nicht-python-spezifische Fragen stellen. Es war eher ein Seitenhieb in die Richtung, dass du mit C++ das selbe Problem hättest

@Sirius3
Datenbankfragen sind hiet trotz des Rubrik-Themas und der Tatsache, dass es um ein in Python realisiertes Programm mit einer Datenbank ja OffTopic, wo mich EyDu ja unmissverständlich drauf hingewiesen hat. Trotzdem möchte ich auf die für mich sehr wichtige Antwort reagieren.

Sirius3 hat geschrieben:Dein Datenbankmodel hat ein echtes Problem, wenn Du 33 Spalten hast. Das kann kein Mensch mehr sinnvoll überblicken.

Diese Tabellenspalte enthält ausschliesslich analoge (dedizierte ?) Daten, die einen Menschen (im weitesten Sinne medizinisch/psychosomatisch) beschreiben und so nicht noch ein zweites mal vorkommen. Es geht auch nicht um Kategorisierung, Mittelwerte, Maxima oder Minima sondern eher um Relationen zwischen einem Einzelnen mit allen Anderen. Schwer zu beschreiben !

Sirius3 hat geschrieben:Wenn Du ein ORM benutzt, sollte ein Parameter-count-mismatch aber auch nicht auftreten.

Die Entscheidung, SQLAlchemy nicht zu benutzen, habe ich unter anderem nach Diskussionen hier in diesem Forum getroffen. Unter .NET hatte ich vor zwei Jahren meine ersten Gehversuche mit ner SQL-Datenbank unternommen und dort (unbewusst) mit dieser ORM-Facility gearbeitet. Dass SQLAlchemie den gleichen objektorientierten Ansatz darstellt, war mir jetzt so nicht bewusst. Wäre mir das klar gewesen, hätte ich meine Entscheidung mit Sicherheit zugunsten SQLAlchemy getroffen. Nun denke ich darüber nach, das mittlerweile schon recht grosse Programm dankenbankmässig nun doch noch mal zurückzurollen. "Unwissenheit schützt vor Strafe nicht" Dann habe ich aber wieder das Problem, dass ich noch nicht weiss, wie ich die PySide-Tableviews mit SQLAlchemy verknüseln soll. Da sind also erst mal wieder Rtfm und Probieren angesagt. Sonderlich gut ist das ganze im Internet nämlich nicht dokumentiert (oder ich war bislang zu blöd zum Suchen...). Als Praktiker brauch ich halt immer Beispiele, um es zu verstehen. References alleine reichen mir da erstmal nicht.

@EyDu
Ja, mit meinem Eiertanz mit C++ habe ich mir hier bei Einigen wohl einiges verdorben.

Wörterbücher fand ich anstatt von Arrays insofern den besseren Ansatz, weil man damit nicht mit Indizes in Form von Zahlen sondern mit "Synonymen" auf Elemente zugreifen kann. Wegen der Komplexität der Algorithmen fand ich das erstrebenswert. Mit Arrays hatte ich häufig mit falschen Indizes gekämpft.

Und was gibt es denn statt einer Datenbank als Container für eine Alternative ? Das Programm soll zunächst Einzeldaten (ein Individuum) und Ergebnisse von Vergleichs-DB-Scans mit OpenGL visualisieren. Später soll die Daten aber auch für das Herausarbeiten neuer Eigenschaften herangezogen werden, die wiederum in der DB gespeichert werden sollen.

Da dieses Programm die Synthese aus zwei Programmen aus früheren Zeiten (in C und Java) sein soll, in das alle meine Erfahrungen und Erkenntnisse mit diesen Programmen, Programmen anderer und der Materie überhaupt einfließen sollen, habe ich mir als Zeitrahmen für die Realisierung ein Jahr auf die Fahnen geschrieben. Deshalb werde ich auch sicherlich jeden guten Ratschlag eines Insiders in meinem Projekt berücksichtigen. Auf "halbe Sachen", die aus meiner Unwissenheit resultieren, habe ich nämlich keine Lust mehr.

Ach Quatsch, du hast dir damit doch nichts verdorben. Für mich ist das eher ein Running Gag, welchen du selbst immer wieder gerne herauskramst. Und da dein jetziges Problem unabhängig von der Sprache ist, war deine Anmerkung natürlich eine Steilvorlage für diesen Seitenhieb

Die Datenstruktur, eine Dictionary mit Strings als Schlüsseln und einer Liste als Wert, wollte ich gar nicht anzweifeln. Da wirst du schon die richtige Wahl für deine Daten getroffen haben. Du musst an dieser Stelle überlegen: welchen Vorteil bringt dir die Datenbank, wenn du das Dictionary und die Listen in Tabellen abbildest? Brauchst du auf den Daten überhaupt alle Datenbank-Features oder fragst du am Ende die Daten doch nur ab und verarbeitest sie dann in deinem Programm? Wenn letzteres der Fall ist, dann handelst du dir möglicherweise nur einen großen Overhead ein und hast im Prinzip keinen Vorteil; außer vielleicht, das alle deine Daten in einer Datenbank liegen. Ansonsten ist auch das Dateisystem eine schöne Datenbank; ggf. Speicherst du einfach Dateinamen in deiner relationalen Datenbank und lädst die Daten dann in den Hauptspeicher.

Einschränkung beim Dateisystem als Datenbank ist natürlich das man da nicht so leicht mit mehreren Benutzern gleichzeitig auf den gleichen Daten/Dateien operieren kann.

Und es gibt noch andere Datenbanken als relationale Datenbank. Stichwort NoSQL.

Nee, nicht schon wieder Files ! Das wird irgendwann wie Flöhe hüten und ich hätte immer sofort direkt zwei Baustellen !

Wir reden jetzt hier ja auch erst mal um meinen Stammdatensatz. Da lade ich mir z.B. einen in den Speicher und vergleiche sie mir anderen aus der Datenbank, wobei ich auch durchaus die Datenbank-Funktionalitäten nutze. Aber z.B. Arrays vergleichen, das kann eine Datenbank nicht.

Was noch für die Datenbank spricht ist mein Vorhaben, dass das System irgendwann mal Gemeinsamkeiten und Unterschiede sammeln soll und dafür ebenfalls ein Container erforderlich ist.

Trotzdem denke ich darüber nach, ob ich nicht doch die dict-Einträge einzeln in die Datenbank bringen sollte, um das simplejson (da gibt es auch noch schnellere Serialisierungen) zu umgehen und noch mehr Datenbank-Facilities nutzen zu können. Aber auf der anderen Seite wären das dann noch mal 83 Spalten mehr

@BlackJack
NoSQL habe ich ehrlicherweise noch nie gehört. Muss ich wohl mal wieder den grossen Vogel bemühen ...

EDIT: Mit NoSQL (CouchDB, Apache Cassandra, MongoDB. OrientDB ?) bin ich aber mit Python/Pyside auf nur schlechtest dokumentiertem Terrain. Und ich habe im Moment auch keine Idee, was mir der Ansatz bringen sollte. Was in Wikipedia steht, hört sich natürlich erst mal gut an. Gibt es denn eine Quelle, wo man sich mal anschauen kann, wie das in der Praxis mit NoSQL und einer relationalen DB bei einunddemselben Fall funktioniert ?

Hallo,

BlackJack hat geschrieben:Einschränkung beim Dateisystem als Datenbank ist natürlich das man da nicht so leicht mit mehreren Benutzern gleichzeitig auf den gleichen Daten/Dateien operieren kann.

Das geht auch mit meiner SQLite meines Wissens nicht...

Die ganze Sache mit meinem Programm hat mir jetzt langes Kopfzerbrechen bereitet, da nun doch einige Aspekte hinzugekommen sind, die meine Denke erst mal vollkommen über den Haufen geworfen haben.

Die 33 (oder mehr) Spalten in einer Tabelle und da dann auch noch jsons drin zu haben, war glaube ich ein sehr schlechter Ansatz, weil ich die Tabellen-Orientierung von relationalen Datenbanken nicht konsequent berücksichtigt habe. Ich hatte mehr oder weniger versucht, ein Konzept auf die Datenbank anzuwenden, welches man bei einer File-Struktur verwendet. EyDu hat mich da ja auch eigentlich deutlich drauf hingewiesen. Ein zu einem Kontext gehörende Datenstruktur in mehreren Tabellen abzuspeichern und halt "relational" mit Indizes auf mehrere Tabellen zu verteilen, da musste ich erst mal von meinen bisherigen (Denk-) Gewohnheiten ziemlich relativieren.

Das Konzept, in meinem Programm mit Dictionaries zu arbeiten, habe ich jetzt aber sogar noch erweitert, in dem ich die in den Dictionaries befindlichen Listen nun auch noch in Dictionaries gewandelt habe, einfach, weil das Arbeiten mit keys wesentlich mehr Spass macht, als Indizes zu verwenden.

Den entsprechenden Teil meines Daten-Kontextes habe ich also entsprechend geändert: Wie könnte man denn nun dieses "Dict of Dicts" tabellenmäßig abbilden ?

Über NoSQL habe ich auch noch Einiges gelesen, bin aber nicht wirklich schlau geworden, ob das für mich interessant sein könnte. Ich habe nichts gefunden, wo das mal so erklärt wird, dass auch ich als DB-Noob das auch verstehe.

Grüße
m-o

@mephisto-online: Mit SQLite können durchaus mehrere Benutzer auf den gleichen Daten operieren. Da dabei immer die gesamte Datenbank gesperrt wird, werden die Zugriffe „zwangsserialisiert”, und wenn eine Transaktion zu lange dauert bekommen andere Benutzer eine Ausnahme wegen der Zeitüberschreitung. Damit kann man dann gegebenenfalls irgendwie umgehen. Was aber im Gegensatz zum Dateisystem nicht so leicht passieren kann, ist das am Ende die Daten kaputt sind, weil sich zwei Benutzer bei Schreibzugriffen in die Quere gekommen sind.

@BlackJack
Dass es bei SQLite so einen Mechanismus gibt, habe ich mir schon gedacht, sonst ginge ja z.B. auch kein Multitheading, wo auch mal zwei Prozesse zur gleichen zeit einen Zugriff benötigen. In den Beschreibungen wird einem die SQLite-DB häufig als "Einbenutzer-Datenbank" verkauft.

@mephisto-online: Einbenutzer deshalb, weil man keine Rechte für verschiedene Benutzer vergeben kann. Dass jeweils die gesamte Datenbank gesperrt wird, ist im Übrigen nicht richtig, aber das sind Details. Ein Dict of Dicts ist im Allgemeinen auch nicht der richtige Weg, wie man Datenbanken designed. Kannst Du mal weg gehen von den abstrakten Beispielen hin zu Deinen wirklichen Daten. Für jeden Anwendungsfall gibt es mal gute, mal schlechte Designs. Ohne zu wissen was Du damit machen willst, kann man schlecht einen Rat geben.

Sirius3 hat geschrieben:Ein Dict of Dicts ist im Allgemeinen auch nicht der richtige Weg, wie man Datenbanken designed.

Aber für Python Programme, wenn man etwas vielschichtere Datenstrukturen braucht.

Sirius3 hat geschrieben:Kannst Du mal weg gehen von den abstrakten Beispielen hin zu Deinen wirklichen Daten.

Wie man die anderen Daten meiner Datenstruktur in einer DB abbildet, ist unproblematisch und entspricht in etwa dem, was üblicherweise in Datenbanken gemacht wird (Kunden, Artikel, Lieferanten...).

Sirius3 hat geschrieben:Für jeden Anwendungsfall gibt es mal gute, mal schlechte Designs.

Wenn man in einem Python-Programm eine für ein gegebenes Problem optimale Datenstruktur benutzt und diese in einer Datenbank als Container halten will, ist das schlechtes Design ?

Sirius3 hat geschrieben:Ohne zu wissen was Du damit machen willst, kann man schlecht einen Rat geben.

Hier steht doch exakt, was ich machen will: Ich möchte ein Dict of Dicts in einer Datenbank abblilden.

Da scheint es jetzt aber für mich das Problem zu geben, dass ich hier mit Datenbank-Problematiken OffTopic bin, wie mir schon unmissverständlich klar gemacht wurde und man mir bei einem Problem mit einem Python-Datentyp in einem Datenbank-Forum auch nicht weiterhelfen kann.

@mephisto-online:Die Struktur in einer relationalen Datenbank zu halten kann ein schlechter Entwurf sein, nämlich dann wenn das was man mit diesen Daten nicht wirklich zu diesem Datenbanktyp passt. Und das Du ein verschachteltes Wörterbuch speichern möchtest ist nicht ausreichend als Beschreibung, denn bei einem DB-Entwurf kann auch wichtig sein was das für Daten sind, wie viele es davon gibt, wie die Verteilung der Werte aussieht, und wie das zu erwartende Zugriffsmuster aussieht. Wonach wird selektiert oder aggregiert werden, und so weiter. Danach entscheidet man letztendlich wie die Daten auf das relationale Modell abgebildet werden.

BlackJack hat geschrieben:Die Struktur in einer relationalen Datenbank zu halten kann ein schlechter Entwurf sein, nämlich dann wenn das was man mit diesen Daten nicht wirklich zu diesem Datenbanktyp passt.

Genau das möchte ich ja abklären ! Für mein Programm ist die Datenstruktur optimal und darüber möchte ich hier auch nicht diskutieren müssen ! Als Datenbank-Typ kenne ich nur relationale Datenbanken. Mit der SQLite komme ich ja auch schon ganz gut klar, jetzt möchte ich halt auch noch gerne ohne die Serialisierungen auskommen können.

BlackJack hat geschrieben:Und das Du ein verschachteltes Wörterbuch speichern möchtest ist nicht ausreichend als Beschreibung, denn bei einem DB-Entwurf kann auch wichtig sein was das für Daten sind, wie viele es davon gibt, wie die Verteilung der Werte aussieht, und wie das zu erwartende Zugriffsmuster aussieht. Wonach wird selektiert oder aggregiert werden, und so weiter.

Das sind alles Aspekte, die interessant werden, wenn es sich um gigantische Datenmengen handelt. Die Grundlagen hierfür habe ich auch schon in grauen Vorzeiten rein theoretisch im Studiium abstrakt durchhecheln müssen. ebay z.B arbeitet mit NoDQL, sicherlich nicht ohne Grund. Bei meinen vielleicht irgendwann mal 1000 Einträgen und der Tatsache, dass es dabei nicht um Millisekunden geht, halte ich diese Diskussion für oversized. Für mich ist die Datenbank nur ein kompfortabler Container für meine Daten mit Möglichkeiten, die ich bei einer Datenhaltung in Files nicht habe.

BlackJack hat geschrieben:Danach entscheidet man letztendlich wie die Daten auf das relationale Modell abgebildet werden.

EyDu hat doch schon geschrieben, wie man das mit einem Dict of Lists machen könnte, dann wird es wohl auch noch eine Lösung für Dicts of Dicts geben.

Nun habt ihr es endgültig geschafft, dass ich mein schon recht fortgeschrittenes Programm-Projekt komplett eingestampft habe. Die ständig massive Kritik an allem, was ich hier vorgetragen habe, hat mich so weit verunsichert, dass ich jetzt schon so weit war, mich nicht nur von Datenbanken, sondern auch von Python zu verabschieden und mit Java weiterzumachen. Das war schon das erste mal der Fall, als ich mich nach Kivy erkundigt hatte, weil ich ein Programm für Android in Python schreiben wollte. Da wurde ich dermassen fertig gemacht, dass ich die App letztendlich in Java geschrieben habe.

Jetzt bin ich schon wieder an diesem Punkt. Ihr könnt vom Glück reden, dass es das einzige deutsche Python-Forum ist, sonst würde nicht nur ich mich von euch abwenden, denn, wie ich in meinem "Netzwerk" feststellen konnte, bin nicht nur ich dieser Meinung.

Eigentlich wollte ich meine Datenstrukturen noch mal weiter spezifiziert hier zur Diskussion stellen, um eine noch bessere Lösung für meinen Container zu finden. Das Naheliegendste wäre ja eigentlich eine reine Python-Lösung (z.B. shelf) , auf die mich hier niemand hingewiesen hat. Da kam dann lapidar ein "Und es gibt noch andere Datenbanken als relationale Datenbank. Stichwort NoSQL.". Der Begriff ORM ist nicht gefallen. Oder vorher wurde mein gesamtes Programm-Konzept als schlecht dargestellt und ich wurde auf "MVC" verwiesen, weil man das halt das so macht, damit man die GUI wechseln kann. Das entspricht nicht der gängigen Praxis in dieser Branche und ist pure, idealisierte Theorie !

Da mein jetziges Vorhaben rein privater Natur ist, kann ich es mir leisten, die Sache erst mal solange ruhen zu lassen, bis ich den Frust und die "Minderwertigkeits-Komplexe", die ich mir in diesem Forum zugezogen habe, vergessen habe und erst mal den Frühlingsanfang zu geniessen. Die Lust zu programmieren, wird schon irgendwann wieder kommen, da bin ich mir sicher. Und vielleicht werde ich mich dann ja auch noch mal an Python heran trauen. Aber dem "EGO-zerstörenden" Einfluss in diesem Forum werde ich mich sicherlich nicht nochmal aussetzen.

Danke für die Unterstützung und die "Gnade", überhaupt auf meine Fragen geantwotet zu haben.

@mephisto-online: Du hast selbst in Deiner Antwort vom 18.März auf meine Antwort hin geschrieben, dass Du ORM nicht magst. Dass Du Ironie nicht verstehst, hast Du schon mehrfach bewiesen, ich kann mir aber leider nicht immer merken, bei welchen Leuten hier ich auf dieses Stilmittel verzichten muß. Dass hier so viele verschiedene, teils sich wiedersprechende Antworten kommen, liegt zum großen Teil daran, dass Du Dein Problem so schwammig stellst. Statt einmal klar zu schreiben, welche Art von Daten Du hast und was Du mit ihnen Anfangen willst, änderst Du Deine Aussagen von Beitrag zu Beitrag. Da bleibt uns auch nur übrig, alle verschiedenen Möglichkeiten, eine Datenbank aufzubauen mal anzusprechen.

@mephisto-online: Man muss dazu aber sagen dass Du Sachen als massive Kritik und „fertig machen” auffasst, die so von den Beitragsverfassern nicht beabsichtigt waren. Du scheinst da ein wenig zum Überreagieren zu neigen, und darauf kann man in einem Medium wie Foren, wo man die Reaktion des Gegenüber deutlich schlechter einschätzen kann als zum Beispiel in einem Gespräch wo man den anderen auch sieht, schlecht sofort reagieren. Ob der Kommunikationspartner auf der anderen Seite etwas in den falschen Hals bekommen hat, bekommt man selbst erst mit wenn es zu spät ist, nämlich dann wenn die entrüstete, enttäuschte, oder sonstig emotional negativ aufgeladene Antwort kommt. Frust der sich „im Stillen” über mehrere Beiträge oder sogar Theman hinweg aufstaut, lässt sich noch schlechter erfassen.

Irgendein Nutzer hatte schon mal ein eigenes Programmierforum erstellt. Das ist sehr leer geblieben. Ist aber letztendlich eine Möglichkeit wenn es tatsächlich eine grössere Gruppe gibt die hier unzufrieden ist, einfach ein eigenes Forum zu eröffnen. Oder die müssten sich mal organisieren und in Dialog mit den Moderatoren/Admins treten und konstruktive Lösungsvorschläge machen wie man die Situation verbessern kann.

Auf der einen Seite beschwerst Du Dich das so viele verschiedene Lösungsansätze für die Datenhaltung in den Raum geworfen werden, auf der anderen Seite dass `shelve` nicht genannt wurde. Da sind wir aber wieder genau an dem Punkt wo man hätte wissen müssen was das für Daten sind und was mit denen gemacht werden soll, also beispielsweise in welchem Muster auf die Daten zugegriffen wird, denn `shelve` geht ja nur wenn die Daten ausschliesslich über *einen* Schlüssel identifiziert werden, und nicht auch nach anderen Kriterien ausgewählt oder gefiltert werden und wenn es keine Redundanzen in den Datensätzen gibt.

Sirius3 hat geschrieben:...dass Du ORM nicht magst...

Woher sollte ich wissen, dass ich ORMs nicht mag, wenn ich noch gar nicht wusste, was das überhaupt ist. Ich hatte nur einen kompfortableren "Wohn-Container" als Files für meine wirklich simplen Daten (die ich auch deutlich beschrieben habe: 33 Spalten, alle einzigartig und zwei davon dicts oder lists) gesucht. Als dann noch jemand vorgeschlagen hat, die Links zu Files in der Datenbank zu halten, hatte ich schon das erste mal fast den Glauben an manche Leute hier (das kann man nie verallgemeinern, es gibt immer solche und solche) verloren.

Und in Python gibt es nun mal auch Lists und Dicts. Dafür gibt es wohl auch ne Menge andere (auf Python zugeschnittene) Lösungen neben dem "üblichen" Ansatz einer relationalen Datenbank. Das wusste ich nicht und damit habe ich auch nicht gerechnet. Datenbankmässig bin ich ein Noob, da habe ich auch nie ein Hehl draus gemacht. Python ist bei mir auch noch recht frisch und ich habe noch keinen rechten Überblick über diese "Welt". Deshalb war ich hier !

Hier https://wiki.python.org/moin/HigherLeve ... rogramming steht:

Some of these might be referred to as object relational mappers, or ORM in this list -- these create Pythonic objects out of database rows

Das werde ich irgendwann mal, wenn mein Bock wieder Fahrt aufgenommen hat, wohl mal genauer studieren und für mich das Passendste heraus suchen.

Und den Vorschlag, doch ein eigenes (2. deutsches) Python-Forum aufzumachen, finde ich wirklich ausgesprochen konstruktiv !

Übrigens ist diese Forums-Software ziemlich buggy ! Da stimmt wohl was mit der Datenbank nicht ! Gerade hätte ich beim Aufruf der Vorschau locker einen Beitrag eines anderen Forum-Mitglieds editieren können. Das ist ein Fehler, der bei Datenbanken ABSOLUT NIE vorkommen darf ! Und das ist nicht das erste Mal, dass hier irgendwelche Abstürze vorgekommen sind. Schon die Uhrzeit stimmt meist nicht, mal hat man Moskau-Zeit, London-Zeit hatte ich glaube ich auch schon. Das relativiert so manche Aussage von einigen (sehr wenigen) hochakademischen, mutmasslich vor Wissen strotzenden, lehrmeisterlich auftretenden, einschüchternden, beleidigenden und auch noch hier massgeblichen Leuten, denen man hier so begegnet.

Aber ich gebe ja zu, es lag alles nur an mir, die Fehler liegen an meinen Browsern und an meinem Rechner ! Seltsamererweise habe ich solche herben Probleme nur hier in diesem Forum. Aber das ist sicherlich auch nur Zufall (oder Einbildung ?).

Schade eigentlich, wo Python wirklich eine so schöne Sprache ist und man jeden nur wohlwollend und verständnisvoll unterstützen sollte, der sich damit befasst oder damit befassen möchte.