mit komprimieren neu id erstellen

[Pitwheazle]

Wenn ich einen Eintrag in der Datenbank lösche und ihn neu erstelle, ist die id ja wohl "weg" und eine neue wird erstellt. Aus meiner Zeit, als ich dBase programmiert habe, glaube ich mich zu erinnern, dass man mit dem Befehl "komprimieren" diese ids neu erstellen bzw. neu zuordnen konnte und die "Karteileichen" so entfernen konnte. Ich vermute, das passiert auch, wenn ich in Thunderbird in einem Orden die Funktion "komprimieren" anklicke. Gibt es das in Django auch?

[__deets__]

Mit einer halbwegs vernünftigen DB wie Postgres oder MariaDB ist sowas nicht notwendig, weil die selbst aufräumen.

[__blackjack__]

@Pitwheazle: Das geht nicht und das *kann* auch nicht gehen, denn die IDs werden ja in anderen Tabellen als Schlüssel verwendet die dann alle auf falsche Datensätze verweisen würden wenn man IDs einfach so neu zuordnen würde.

Die IDs haben nichts damit zu tun wie die Daten auf dem Datenträger organisiert sind. ”Lücken” in den IDs müssen weder bedeuten, dass es ”Lücken” in der oder den Datendateien gibt, noch bedeuten ”lückenlose” IDs, dass es nicht ungenutzten Speicher in der oder den Dateien gibt. Die ID oder besser der Primärschlüssel ist Teil des Datensatzes als *Datum* und nicht wie die Datensatznummer in DBF-Dateien eine Zahl die nicht im Datensatz gespeichert wird, sondern im Grunde die Position eines Datensatzes in einer Datei beschreibt. Ein umnummerieren macht also nur Probleme, und hat keinen Vorteil was den belegten Plattenplatz angeht.

Je nach dem welches DBMS verwendet wird und wie die Daten konkret auf dem Datenträger organisiert sind, kann es Stellschrauben geben die Daten auf Speicherplatz zu optimieren. Das hat aber alles nichts mit Django oder Python zu tun. Da muss man sich mit der konkreten Datenbanksoftware beschäftigen und deren Werkzeuge oder APIs um an Parametern zu schrauben.

Das einzige was unabhängig vom DBMS gleich ist, wäre ein Sichern der Daten als SQL-Dump, löschen der Datenbank, und neu erstellen/füllen aus dem Dump.

Die Daten werden in aller Regel nicht so simpel linear und lückenlos in einer Datei gespeichert wie bei xBase. Und in einigen der üblicherweise verwendeten Datenstrukturen in der Datensätze gespeichert werden, ist es sogar gewollt das da ungenutzter Speicher ist. Beispielsweise bei B-Trees ist es sinnvoll nicht immer komplett gefüllte Knoten zu speichern, weil Knoten aufteilen oder zusammenfügen relativ teure Operationen sind und die Performance besser ist, wenn man das nicht so oft machen muss.

Hast Du überhaupt ein tatsächliches Problem oder ist das nur so ein Bauchgefühl?

[Pitwheazle]

Das geht nicht und das *kann* auch nicht gehen, denn die IDs werden ja in anderen Tabellen als Schlüssel verwendet die dann alle auf falsche Datensätze verweisen würden wenn man IDs einfach so neu zuordnen würde.

Das leuchtet ein.

Hast Du überhaupt ein tatsächliches Problem oder ist das nur so ein Bauchgefühl?

Nun ja, kein Problem das sich nicht lösen ließe. Mein Projekt baut ja auf einer Struktur auf, die mir @whitie gebastelt hat. Beim Aufruf meiner verschiedenen (Rechenaufgaben-) Kategorien wird mittels eines Dictonairies jeweils eine Funktion aufgerufen. Diese sind im Original mittel der Kategorie ID verknüpft. Eine Kategorie habe ich versehentlich gelöscht und neu angelegt, dadurch stimmt die Zuordnung nicht mehr. Das werde ich ändern.

Vielen Dank für die sehr ausführlich Erklärung.

[__deets__]

Für sowas bietet sich üblicherweise ein expliziter, händisch vergebener Schlüssel an. Statt einer generierten ID. So wie zb einen ISO Ländercode (DE, UK,…) statt 47, der ID der Zeile (47, “Deutschland”), die sich dann einfach auch mal ändern kann. Und deine Kategorien sind ja von dir festgelegt, und kommen nicht von außen magisch in das System, und plötzlich kann das Aufgaben zur Fouriertransformation.

[noisefloor]

Hallo,

du hast da noch zwei kleinen Gedankenfehler drin. Die ID kann in einer DB etwas bedeuten, muss aber nicht. Man braucht bei einem RDBMS ja "nur" einen Primärschlüssel - kann eine ID sein, muss aber nicht.
Und wenn die ID dein Primärschlüssel ist, dann muss die ID ja "nur" einmalig sein. Die meisten (mir bekannten) RDBMS zählen zwar monoton von 1 an hoch - aber das ist kein muss. Du könntest ja z.B. auch eine UUID verwenden, kombiniert mit der Prüfung, dass die UUID dummerweise nicht schon in der DB vorkommt (unwahrscheinlich, aber nicht unmöglich).

Wie __blackjack__ schon sagte: die low-level Implementierung der Datenstruktur in der DB kann dir erstmal egal sein. Falls du an die Leistungsgrenze deiner Applikation kommen solltest, dann solltest du erst nach "slow queries" schauen oder die Hardware, auf der die DB läuft, aufrüsten oder die DB horizontal skalieren oder mehr Caching betrieben etc.

Oder, was die neueren Django Versionen ja können bzw. was bei zukünftigen Django Versionen noch ausgebaut wird, deine Django App auf asynchron umbauen (https://docs.djangoproject.com/en/4.1/topics/async/).

Aber ich denke, du bist von der Notwendigkeit solcher Optimierungen noch ziemlich weit weg.

Gruß, noisefloor

[Sirius3]

Dann hat Deine ID ja über die Datenbank hinaus eine Bedeutung.
Sollte also nicht automatisch generiert werden, sondern auch händisch eingeben werden.