Update für ca. 4 Mio Datensätze

Für Themen zu Datenbanken und Zugriff auf diese. Auch für Datenbankkomponenten.
charlytango
Beiträge: 681
Registriert: Sa 12. Sep 2015, 12:10
OS, Lazarus, FPC: Laz 2.2.4
CPU-Target: Win 32Bit, 64bit
Wohnort: Wien

Re: Update für ca. 4 Mio Datensätze

Beitrag von charlytango »

Nihao hat geschrieben:
Fr 20. Jan 2023, 18:59
Bei meiner Frage ging es nur um ein SQL Statement.
Eventuell war die Frage auch einfach nur zu schwer.
Ich habe dir zwei Lösungen für deine Frage geliefert. Und eine Menge an Hintergrundinfo und Ablaufvorschlägen. Nur muss man dazu etwas mehr als zwei Zeilen lesen. Oder ggfs auch mal fachlich drauf reagieren um präzisere Lösungen zu erhalten.

Scheinbar war meine Antwort zu schwer.

martin_frb
Beiträge: 558
Registriert: Mi 25. Mär 2009, 21:12
OS, Lazarus, FPC: Laz trunk / fpc latest release / Win and other
CPU-Target: mostly 32 bit

Re: Update für ca. 4 Mio Datensätze

Beitrag von martin_frb »

Wo ist das Problem mit den vorgeschlagenen SQL ?

Der "join" von charlytango ist mehr oder weniger die Standard Lösung...

Klar ist, es wird ein wenig Zeit in Anspruch nehmen. Aber es kann doch im Hintergrund vor sich hinlaufen?

Joh
Lazarusforum e. V.
Beiträge: 77
Registriert: Sa 26. Mai 2012, 17:31
OS, Lazarus, FPC: Win 10 (L 2.2.4 x64 FPC 3.2.2)
CPU-Target: 64Bit

Re: Update für ca. 4 Mio Datensätze

Beitrag von Joh »

Das Problem ist, das du ein relationales Datenbanksystem hast.
Das beraubst du der hauptsächlichen Eigenschaft: der Relationalität.

Du erkaufst dir für ein paar Bytes (6 Mio. x Speicherplatz für Datum) abzgl. 600.000 Rechnungsdatensätze
kaputte Relationen (obwohl, die Rechnungsnummer könnte man dann ja auch löschen, die zeigt eh ins Nirvana).

Dazu kommt der o.g. rechtliche Aspekt und: vor Allem: der Sinn des ganzen.
Bei mir hat ein Rechnungskopf z.B. 280 Bytes. Das ist dem geschuldet, das ich in jeder Rechnung die komplette Anschrift speichere. Wenn die
2016 Lazarusforum e.V. in Berlin war und
2023 auf Lazarusforum AG in Osnabrück <g>
geändert wird, dann ist das immer noch der gleiche Kunde aber in den Rechnungen unterschiedlich...

Also: 600.000 x 280 - 2 Mio x 10 (?) sind 148 Mio Bytes.
Also 141 MB...
Selbst bei einer Mini-SSD sind 141 MB nur P e a n u t s.
(hier vergesse ich die Index-Daten absichtlich; aber ein BTree kostet auch nicht die Welt)

Aber: wenn der TE nur Speicherplatz sparen möchte, sollte er doch den Rechnungskopf belassen und z.B. nur die Rechnungsnummer und das Datum belassen => das spart wesentlich mehr Bytes.

Ob das Sinn ergibt oder nicht ist mir dann auch wumpe.

Benutzeravatar
gladio
Beiträge: 199
Registriert: Sa 21. Jun 2014, 06:15
OS, Lazarus, FPC: Win10-64 - aktuelle Lazarus/FPC Standard-Edition
CPU-Target: 64Bit
Wohnort: Rügen

Re: Update für ca. 4 Mio Datensätze

Beitrag von gladio »

Ein Datumsfeld in den einzelnen Rechnungspositionen ist durchaus nicht sinnfrei.
Eine Rechnung kann über mehrere Tage geführt werden bis sie geschlossen wird.
Ist in der Hotellerie so üblich.

Andererseits sollte es in einem Programm oder Datenbank nicht möglich sein,
die Rechnung zu löschen ohne vorher auch die dazugehörigen Positionen zu löschen (nach Ende der Aufbewahrungsfrist).

charlytango
Beiträge: 681
Registriert: Sa 12. Sep 2015, 12:10
OS, Lazarus, FPC: Laz 2.2.4
CPU-Target: Win 32Bit, 64bit
Wohnort: Wien

Re: Update für ca. 4 Mio Datensätze

Beitrag von charlytango »

Egal wie wir versuchen zur Lösung beizutragen, wenn der Poster das nicht zulässt oder fehlende Hintergrundinformationen bereitstellt ist das alles nur Kaffeesudlesen
Nihao hat geschrieben:
Fr 20. Jan 2023, 14:24
Es geht nur um eine technische Frage.
.....
Die Technik ist entscheidend nicht das warum?
In diesem Punkt bin ich überzeugt dass der Poster irrt.
Es ist nie alleine die Technik sondern immer eine Folge des "Warum".
Wäre es wirklich nur um die Technik gegangen hätte der Kontext von Rechnungslegung keine Rolle gespielt.
Und dann wäre die Beteiligung an dem Post wohl eher mau gewesen mit dem Hinweis RTFM
Nihao hat geschrieben:
Fr 20. Jan 2023, 18:59
weil der die eigentliche Frage, die Überschrift, nicht beantwortet findet.
Und die Dünnhäutigkeit führt zu Scheuklappen die verhindern zu sehen dass längst Lösungen angeboten wurden. Nur wurden die nicht so präsentiert wie er sich das vorgestellt hat, deswegen gelten sie für ihn nicht. Eine schnelle Lösung ohne Tiefgang scheint im Moment der zug der Zeit zu sein.
Nihao hat geschrieben:
Fr 20. Jan 2023, 18:59
Mein Fehler, ich wusste nichts von dieser erweiterten Fürsorge.
Sarkasmus anstelle von Auseinandersetzung mit dem Thema. Aktuell auch ein gängiges Modell.
Nihao hat geschrieben:
Fr 20. Jan 2023, 18:59
Werde mein Glück in einem SQL-Forum suchen. Nichts für ungut, Bye.
Und die Flucht wenns selbst verschuldet zu eng wird.
Zumindest angekündigt und nicht wortlos.

Ich bin raus aus dem Kabarett.

Antworten