Update für ca. 4 Mio Datensätze

[Nihao]

Hallo,

ich habe in einer DB 2 Tabellen.

1. Rechnungen (ca. 600k)
2. RNG-Pos (ca. 4Mio)

Nun brauche ich das Datum (erstellt) aus der Tabelle 1 fix bei den Positionen. (Tabelle 2)

Ich will keine 600k Updates schicken, das würde ewig dauern.

Ein Join bei der Abfrage geht auch nicht, denn wenn jemand das Rechnungsdatum in Tabelle 1
ändert muss das Original bei den Positionen bleiben!

Wie sage ich es meinem Server?

Irgendwie so?

Code: Alles auswählen

UPDATE tabelle2 SET tabelle2.datum = tabelle1.erstellt WHERE tabelle2.rid = tabelle1.rid; 

[Socke]

Wie sage ich es meinem Server?

Irgendwie so?

Code: Alles auswählen

UPDATE tabelle2 SET tabelle2.datum = tabelle1.erstellt WHERE tabelle2.rid = tabelle1.rid; 

Du hast da schon einen Ansatz. Hast du den schon ausprobiert?

[charlytango]

Nun brauche ich das Datum (erstellt) aus der Tabelle 1 fix bei den Positionen. (Tabelle 2)

könntest du vielleicht erläutern warum du das Datum statt an einem Punkt (in der Rechnung) nun auch in den Rechnungspositionen brauchst? Vom DB Design her macht das für mich im Moment keinen Sinn. Und Abfragen über die Rechnungspositionen kannst du ja auch über einen bereits vordefinierten View laufen lassen, der in deinem Fall wohl ziemlich schnell sein sollte. Views sind quasi virtuelle Tabellen die schon vorbereitete Abfragen enthalten die ihrerseits wie Tabellen benutzt werden können.

Ein Join bei der Abfrage geht auch nicht, denn wenn jemand das Rechnungsdatum in Tabelle 1
ändert muss das Original bei den Positionen bleiben!

Natürlich ist das was du tun musst ein JOIN auch wenn es in deiner Syntax vielleicht nicht so auffällig ist. Um da näheres sagen zu können wären Informationen hilfreich wie: Welcher SQL Server in welcher Version?

Und um zu verhindern dass ein Benutzer während der Ausführung des Statements etwas ändert gibts einige Varianten die je nach SQL-Server-Typ möglich sind oder nicht.
Testen würde ich das auf jeden Fall in einer eigenen Instanz der Datenbank und nicht in der produktiven DB. Dann weißt du auch wielange das Statement läuft.

-- Datenbank in den Single User Modus (oder Admin-Modus) versetzen. Gibt es nicht überall

-- Das Statement in eine Transaktion packen -- alles oder nichts Prinzip.

-- DB-Wartung klarerweise außerhalb der Betriebszeiten

-- komplexer: Vor dem ausführen des Updates einen INSERT/UPDATE-Trigger schreiben der beide Felder synchron hält (so etwas ist ohnedies nötig um das in Zukunft zu synchronisieren wenn du keinen Zugang zum Programm hast)

Code: Alles auswählen

UPDATE tabelle2 SET tabelle2.datum = tabelle1.erstellt WHERE tabelle2.rid = tabelle1.rid; 

Nachdem das Statement ja in jedem Fall ein Join ist, ist es nur mehr eine Frage der Syntax

Code: Alles auswählen

UPDATE tabelle2, tabelle1
SET tabelle2.datum = tabelle1.erstellt 
WHERE tabelle2.rid = tabelle1.rid; 

Sollte als SQL92-Syntax von jedem halbwegs aktuellen SQL-Server verstanden werden.

Code: Alles auswählen

UPDATE tabelle2
JOIN tabelle1 ON tabelle2.rid = tabelle1.rid
SET tabelle2.datum = tabelle1.erstellt;

Das ist zb MariaDB-Syntax.
Empfehlungen OHNE Gewähr

[Nihao]

Erst einmal Danke für die Antworten.

Nun zur Frage warum?

Ich habe bei den Positionen zur Rechnung auch die Kunden ID und kann so bei jeder neuen Rechnung, sehr schnell die bereits gekauften Kundenprodukte abrufen. Diese sollten aber nach Datum des Kaufs sortiert sein.

Da Rechnungen nach einer gewissen Zeit ausgelagert/gelöscht werden, die Positionen aber nicht, eben wegen der Kunden-Produkt-History, brauche ich dort das Datum.

Das ist alles.

[Joh]

ähem...

Also, um ein wenig Platz zu sparen (die Rechnungsköpfe zu löschen) wird an anderer Stelle Redundanz gefordert?
Da hat man ein relationales System und führt es ob irgendwelcher Begründungen ad Absurdum?

Es existieren z.B. Indizes... Dann sind Abfragen über mehrere Tabellen auch nicht mehr sooo langsam), auch wenn du das nicht glaubst.

Was sind 4 Mio. / 600k Datensätze? Da lacht doch jedes Datenbanksystem drüber.
Was du vor hast, ist Denken aus den frühen 80er Jahren des vorigen Jahrhunderts.

[charlytango]

Was sind 4 Mio. / 600k Datensätze? Da lacht doch jedes Datenbanksystem drüber.
Was du vor hast, ist Denken aus den frühen 80er Jahren des vorigen Jahrhunderts.

hab ich jetzt nicht gewagt in mein voriges Posting zu schreiben, deckt sich aber absolut mit meiner Erfahrung.
Offloading von Daten macht bei solchen Dimensionen IMHO wenig Sinn. Da ist der Overhead größer als die Kosten für eine neue Platte bzw größeres RAID.
Selbst wenn ich es historisch sehe (also in die Tabelle der Rechnungsköpfe alle Daten direkt nochmal reinschreibe und nicht nur die Schlüssel verwende) macht Offloading für mich datenbanktechnisch keinen Sinn.

Einzig buchhalterische und legistisch-strategische Überlegungen im Sinn von "Daten über die gesetzliche Behaltepflicht habe ich einfach nicht" könnten IMHO hier greifen. Wirtschaftlich machts bei den Plattenpreisen um etwa €25 pro TB auch keinen Sinn.

...aber jeder wie er mag

[martin_frb]

Ich habe bei den Positionen zur Rechnung auch die Kunden ID und kann so bei jeder neuen Rechnung, sehr schnell die bereits gekauften Kundenprodukte abrufen. Diese sollten aber nach Datum des Kaufs sortiert sein.

Da Rechnungen nach einer gewissen Zeit ausgelagert/gelöscht werden, die Positionen aber nicht, eben wegen der Kunden-Produkt-History, brauche ich dort das Datum.

Ich kann mir zwar vorstellen das aus Datenschutz/Sicherheit bestimmte Daten nur begrenzt gelagert werden.... Bin nicht sicher ob das hier der Fall ist.
Wenn das der Fall ist: Bravo. Denn die meisten sind zu Faul da was zu tun.

Wenn es um Kosten sparen (Server mit weniger Resourcen geht), wie andere schon angemerkt haben, bei so viel Kunden Aktivität sollte ein Upgrade möglich sein. Oder aber es ist das falsch DB backend.

---------------------

Ich würde das Datum nicht verschieben sondern

table RECHNUNG_MAIN
id
date
// ggf laufende nummer

table RECHNUNG_DETAIL
id
was immer sonst derzeit in rechnung ist

table RNG_POS
bleibt wie bisher

Dann kannst Du rows in RECHNUNG_DETAIL entfernen wann immer Du möchtest.

-------------------
Geschwindigkeit sollte das nicht wirklich beeinflussen.
Falls doch, oder falls Geschwindigkeit eine Issue ist, dann sind die Indexe nicht gut geplant.

Und wenn es wirklich so heiß hergeht, das es dauernd Wartezeiten gibt, ggf
- Tabellen partitionieren (wichtig ist gute Kriterien zu finden).
- Indexes mit kompletten Daten für bestimmte Queries "index only lookup" (besonders in Kombination mit "conditional index")
- Conditional indexes, z.B nur für offene Rechnungen, oder für Rechnungen in einem Bestimmtem Bearbeitungszustand (Wenn hier andere Abfragen angewandt werden)

[Nihao]

Das ist eher eine Frage der Ideologie. Ich gehöre noch zu einer Generation die versuchen ein System „schlank“ zu halten und nicht mehr benötigten Overhead zu löschen. Sonst „müllt“ sich jedes System irgendwann zu.

Preise und Wirtschaftliche Aspekte waren auch nicht der Sinn meiner Frage, es ging nur um die technische Umsetzung.

Wenn niemand mehr etwas Sinnvolles zur eigentlichen Frage beizutragen weiß, kann dieser Thread geschlossen werden.

[Winni]

Hi!

Die Aufbewahrungsfrist für alle relevanten Geschäftsvorgänge in Firmen beträgt 10 Jahre.
Also auch für Rechnungen.

Wenn die Unterlagen elektronisch erstellt worden sind, gilt das also auch für die elektronischen Unterlagen.

Damit die Unterlagen nicht verschwinden bei etwaigem Schaden (Feuer, Flut, etc) muss eine tagaktuelle Sicherheitskopie außerhalb des Hauses vorhanden sein.

Winni

[m.fuchs]

Das ist eher eine Frage der Ideologie. Ich gehöre noch zu einer Generation die versuchen ein System „schlank“ zu halten und nicht mehr benötigten Overhead zu löschen. Sonst „müllt“ sich jedes System irgendwann zu.

Das ist grundsätzlich löblich, aber hier nicht sinnvoll. Daten die nicht mehr gebraucht werden kann man durchaus löschen, aber diese Daten brauchst du ja offensichtlich noch.

Winni hat ja schon auf die Aufbewahrungsfristen für Unterlagen die mit geschäftlicher Buchhaltung zu tun haben hingewiesen. Dadurch müssten Daten zu einem Kauf am heutigen Tag bis einschließlich 01.01.2035(!) aufbewahrt werden. Und wenn 2035 für deine Kunden ein gekauftes Produkt aus dem Jahre 2023 noch relevant ist, dann kannst du dir auch wirklich den Platz für die zugehörigen Rechnungen gönnen.

[Nihao]

Ihr versteht mich nicht.

Es geht nur um eine technische Frage. Wie bekomme ich Daten am schnellsten von einer Tabelle in eine andere.

Ob es sich um Rechnungen, Ersatzteile, Briefmarken oder Paganinibilder handelt ist völlig egal.

Die Technik ist entscheidend nicht das warum? Es war ein Fehler von mir auf diese Frage zu antworten!

[m.fuchs]

Du verstehst uns nicht.

In diesem Forum herrscht - und das ist eine schöne Ausnahme im Vergleich mit vielen anderen Foren - die Auffassung vor dass Fragen nicht nur technisch beantwortet, sondern - sofern Hintergrundinformationen vom Fragenden mitgeliefert werden - auch Vorschläge für eine andere/bessere Vorgehensweise geliefert werden.
Das hilft oft vielen Fragenden dabei eine viel bessere/schnellere/einfachere Lösung für ihr Problem zu finden.

Das kannst du jetzt überflüssig finden - kann dir aber auch egal sein. Niemand von uns wird morgen in deinem Büro auftauchen, dir eine 9mm-Halbautomatik an den Kopf drücken und dich dazu zwingen den von uns vorgeschlagenen Weg zu wählen.

Aber eventuell wird jemand mit einer ähnlichen Fragestellung irgendwann einmal diesen Thread lesen - und sich dann daran erfreuen dass er hier den Sachverhalt von mehreren Seiten beleuchtet vorfindet.

[Nihao]

... oder er wird gefrustet zu einem anderen Forum wechseln, weil der die eigentliche Frage, die Überschrift, nicht beantwortet findet.

Bei meiner Frage ging es nur um ein SQL Statement. Da ich in diesem Fall die Lazarus-IDE nutzen wollte, habe ich die Frage in dieses Forum geschrieben. Mein Fehler, ich wusste nichts von dieser erweiterten Fürsorge.

Eventuell war die Frage auch einfach nur zu schwer. Werde mein Glück in einem SQL-Forum suchen. Nichts für ungut, Bye.

[Winni]

Verwurgstes DB-Design bleibt verwurgstes DB-Design.

Da hilft auch kein anderes Forum.

[af0815]

一会儿见