Update für ca. 4 Mio Datensätze

[charlytango]

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]

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]

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.

[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]

Egal wie wir versuchen zur Lösung beizutragen, wenn der Poster das nicht zulässt oder fehlende Hintergrundinformationen bereitstellt ist das alles nur Kaffeesudlesen

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

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.

Mein Fehler, ich wusste nichts von dieser erweiterten Fürsorge.

Sarkasmus anstelle von Auseinandersetzung mit dem Thema. Aktuell auch ein gängiges Modell.

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.