Laden...

Frage bezügl. Geschwindigkeit vs. Redundanz

Erstellt von barzefutz vor 12 Jahren Letzter Beitrag vor 12 Jahren 1.990 Views
B
barzefutz Themenstarter:in
95 Beiträge seit 2007
vor 12 Jahren
Frage bezügl. Geschwindigkeit vs. Redundanz

verwendetes Datenbanksystem: MS SQL Compact Edition

Hi,

ich bräuchte mal eure Hilfe bezüglich einer konzeptionellen Frage zu meiner Datenbank. Ich habe (vereinfacht dargestellt) eine Datenbank, in der Finanztransaktionen zu bestimmten Märkten gespeichert werden. So in der Form:

Markt 1:

Transaktion 1, -1000€
Transaktion 2, +1200€

Markt 2:

Transaktion 1: +300€
Transaktion 2: -800€

Also zwei Tabellen, in der einen sind die Märkte gespeichert, in der anderen die Transaktionen, die auf diesen Märkten abgeschlossen werden. Ich möchte dann eine Abfrage erstellen, die mir eine Übersicht nach Datum ermöglicht, wieviel Gewinn bzw. Verlust an jedem Tag erzielt wurde, also so:

11.12.2011: -300€
12.12.2011: +250€

Diese Übersicht wird ziemlich oft aufgerufen und soll für 30 Tage rückwirkend einsehbar sein.

Jetzt meine Frage: Es müssen da ja ziemlich viele Daten abgerufen werden. Für jeden Tag müssten alle Märkte abgerufen werden, und dann nochmal zu jedem Markt alle Transaktionen, und dann müsste man alles zusammenrechnen. Wäre es nicht besser, zu jedem Markt als Eigenschaft den Gewinn/Verlust extra zu speichern? Man würde damit die Geschwindigkeit steigern, aber mehr Speicherplatz verbrauchen und gegen das Prinzip verstoßen, jeden Wert nur einmal zu speichern. Eigentlich ist das ja nicht erlaubt, weil es eine Redundanz darstellt, denn der Wert kann ja auch aus den ganzen Daten berechnet werden. Aber wenn man ihn extra speichern würde, wären die Abfragen natürlich weit weniger rechenintensiv, und die Datenbank soll auch auf schwachbrüstigen Systemen lauffähig sein (es wird SQL Compact Edition verwendet, also kein Datenbankserver). Wie würdet ihr das machen? Das Ganze erscheint vielleicht etwas banal, aber ich würde gerne mal ein paar andere Meinungen einholen, bevor ich das ganze in Angriff nehme.

C
1.214 Beiträge seit 2006
vor 12 Jahren

Probiers halt aus. Wenn das schnell genug läuft, würde ich keine redundaten Informationen speichern (premature optimization ist the root of all evil ist ein beliebtes Zitat hier im Forum). Kommt drauf an, wieviele Datensätze du erwartest. Wenn es sich um paar hundert oder paar tausend handelt, ist es kein Problem. Bei mehreren zehntausend weiß ichs nicht. Bei Aggregaten über Milliarden von Datensätzen würd ich schon erwarten, dass es ein bisschen was dauert... Dann kannst vielleicht noch eine zusätzliche Statistics Tabelle einführen, die die vorberechneten Daten hält und ab und zu aktualisiert wird.

B
barzefutz Themenstarter:in
95 Beiträge seit 2007
vor 12 Jahren

Stimmt, du hast eigentlich völlig recht. Man sollte sich erst Gedanken um sowas machen, wenn es notwendig wird, das habe ich schonmal irgendwo anders gelesen. Ich war mir halt nicht sicher, ob man nicht jetzt schon absehen könnte ob es zu langsam wird, da ich keine Erfahrung mit der Geschwindigkeit von SQL Server Compact habe. Aber in diesem Fall wäre es ja nicht allzu aufwendig, die "Optimierung" nachträglich einzufügen 😃

Edit: Es gibt sogar ein Fachwort dafür: "Denormalisierung"

Denormalisierung

War mir als Anfänger bisher nicht bekannt, vielleicht interessiert der Link ja jemanden 😃

V
5 Beiträge seit 2011
vor 12 Jahren

Hi,
ich sehe erst mal kein Problem bei der Abfrageerstellung. Aber Datentyp mäßig evtl. solltest du
entweder mit Type Date arbeiten oder noch besser mit drei Property Jahr, Monat, Tag. Dann schätze ich kannst du einfach und flexible dein „Group By Klausel“ schreiben mit entsprechende. „Where oder Having Bedingung“.
Gutes Neu Jahr an alle!