Performance Vergleich

Beiträge zum Forumthread

Beiträge zu diesem Forumthread

Betreff

Datum

Anwender

Hallo Flo,
das ist eher eine akdemische Frage nehme ich an. In der Praxis dürfte das für die Geschwindigkeit irrelevant sein, weil beides sich nicht viel nehmen wird. Falls Du tausende von Ergebnissen anzeigen lassen musst, kann sich das auswirken. Dann müsstest Du messen, was wieviel schneller ist. In der Praxis macht das für ein paar Datensätze keinen (gefühlten) Unterschied.
Die interessantere Frage ist, wie Du die Daten ablegst und welche. Der Mehrwertsteuersatz macht nur Sinn für jeden Datensatz, wenn Du die Unterschiedlichen Sätze berücksichtigen musst. Sonst ist das nur eine einzige Konstante. Ansonsten sind es zwei Konstanten und Du legst in den Datensätzen ab, welche verwendet wird. Damit wäre eine Anpassung neuer Sätze leicht, da nur die beiden Konstanden geändert werden müssen. Weiterhin ist Brutto und Netto nicht notwendig, weil das redundant gespeicherte Informationen sind. Hast Du Brutto und den Stuersatz, kannst Du Netto einfach ausrechnen.
Nach DB Dogma legst Du so wenig Daten wie möglich ab, also keine Redundanzen, keine mehrfache Datenhaltung. Wie gesagt, wenn es um Geschwindigkeit geht ist es schon oft so, dass der Einsatz von mehr Speicher da helfen kann. Das musst Du aber im Zweifelsfall wirklich ausprobieren.
Viele Grüße,
Zwenn

Hi Flo,
mit DB Dogma bin ich mal wieder etwas flappsig mit einer Formulierung umgegangen, die ich nicht von Deiner Sicht aus betrachtet habe. Sorry. Echte (relationale) Datenbanken werden normalisiert, um sie in die optimale Form zu bringen. Das meine ich mit Dogma. Es gibt genaue Regeln, nach denen (Meta-)Daten "geknetet" werden können, damit sie so vorliegen (und weitere gleichartige Daten abgelegt werden können), dass sie bei der Verwendung optimal verarbeitet werden können.
https://www.datenbanken-verstehen.de/datenmodellierung/normalisierung/
Mit Meta-Daten meine ich, es werden die Oberbegriffe betrachtet. Sozusagen die Kopfzeilen von Tabellen. Das können Daten sein wie Straße, Ort, Nachname, Vorname, usw. Die enthalten noch nix spezifisches, aber es ist klar, welche Art von Daten in diesen jeweils so bezeichneten Datenfeldern abgelegt werden sollen.
Mit echte Datenbanken meine ich hier relationale Datenbanken. In Excel selbst erstellt man keine echten Datenbanken, sondern es können Daten in Tabellen abgelegt werden. Wird das in einer sehr strukturierten Form gemacht, können die einzelnen Zeilen einer Tabelle durchaus als Datensätze betrachtet werden. In Excel wird aber (zumeist) von einer einzigen Tabelle ausgegangen, die eine "Datenbank" abbildet. Echte Datenbanken bestehen aber zumeist aus mehreren Tabellen (Relationen), die sich aufeinander beziehen, um Bezüge zueinander abzubilden. Diese Bezüge werden benötigt, um z.B. Personen und Adressen in unterschiedlichen Tabellen nachzuhalten. Der Grund ist wieder die Vermeidung doppelter Datenhaltung. Wohnen zwei Personen an der gleichen Adresse, werden in der Tabelle "Personen" zwei Datensätze angelegt, die sich beide auf einen einzigen Datensatz in der Tabelle "Adressen" beziehen. Der Bezug wird über weitere Spalten in den Tabellen sichergestellt, die das Datenbanksystem verwaltet. Oft werden dafür IDs als sogenannte Schlüssel verwendet:
https://www.oracle.com/de/database/what-is-a-relational-database/ (Artikel ist auf Deutsch)
In Excel schreiben wir oft Personen und Adressen in die gleiche Tabelle, jeweils alles in eine Zeile. Haben wir aber mehrere Personen, die unter der gleichen Adresse erreichbar sind, werden die Adressen mehrfach in den Daten auftauchen. Hat eine Person mehrere Adressen, unter denen sie erreichbar ist, wird die Person mehrfach in den Daten auftauchen. Genau so funktionieren echte Datenbanken aber nicht. Es gibt dort wie gesagt zwei Tabellen für Adressen und Personen. Es werden "einfach" die Datensätze zwischen den Tabellen verknüpft, die etwas miteinander zu tun haben. Es wird hier auch von den beiden Entitäten Personen und Adressen gesprochen.
Auch Excel kann als "Datenbank-Simulation" verwendet werden, wenn mehrere Tabellen in Beziehung zueinander verwaltet werden sollen. Aus eigener Erfahrung kann ich aber sagen, das ist einigermaßen aufwändig, weil nämlich die genannten IDs alle selbst mit verwaltet werden müssen. Nicht zu empfehlen.
In Excel ist es (aus meiner Sicht) für kleinere Projekte absolut OK Daten in einer Tabelle vorzuhalten, auch wenn da mehrfache Datenhaltung vorkommt. Bei mehreren tausend Datensätzen und mehr, würde ich aber lieber auf eine echte Datenbank als Datenspeicher zurückgreifen. (Allerdings auch je nach Anwendung. Reine Datenerfassung geht auch mit mehr als 100tsd Zeilen problemlos in einer Tabelle, wenn man weiß, was man macht.) Das führt uns zwingend zu einem weiteren Punkt. Datenspeicherung, Datenverarbeitung und Datenausgabe. Oder um etwas kürzer auf das alt hergebrachte EVA-Prinzip zurückzukommen ... Eingabe, Verarbeitung, Ausgabe. Das sind also drei Schritte die sich im vorliegenden Zusammenhang folgendermaßen ergeben.
Die Eingabe, bzw. Datenspeicherung wird über das Backend realisiert. Um es einfach auszudrücken, werden die Daten im Hintergrund gespeichert und verwaltet. Die Daten ansich sind in diesem Zusammenhang als Ansammlung unterschiedlichster Informationen zu verstehen, die in den meisten Fällen nix miteinander zu tun haben. "Nix miteinander zu tun" bedeutet im vorliegenden Beispiel, die meisten Personen wohnen nicht an den meisten Adressen. Aber natürlich sind die Beziehungen zwischen den Daten ebenfalls nachgehalten. (Backend bezieht sich hier auf ein Datenbanksystem)
Die Verarbeitung, bzw. Datenverarbeitung wird über die Middleware realisiert. Wie der Name bereits sagt, steht dieser Schritt zwischen der Eingabe und der Ausgabe (in der Mitte). Darauf komme ich nach der Erklärung zur Ausgabe noch einmal zurück.
Die Ausgabe, bzw. Datenausgabe wird als Frontend bezeichnet. Im Zusammenhang mit Datenbanken wird dabei auch von der Datenbankanwendung gesprochen. Im Wortsinn also "die Datenbank (mit den darin gespeicherten Informationen) wird verwendet". Hier ruft ein Anwender also z.B. Daten aus der Datenbank ab, die sich auf den Vornamen "Peter" beziehen. Im Grunde der gleiche Vorgang, wie bei jeder Abfrage einer Suchmaschine im Internet. Es wird eine Ergebnismenge zur Anfrage zurück geliefert, die den Suchkriterien entspricht.
An dieser Stelle kommen wir auf die Middleware zurück. Denn die Eingabe ins Frontend, um aus dem Backend die gewünschten Informationen zu erhalten, muss ja irgendwo verarbeitet werden. Die Verarbeitung, also die Vermittlung zwischen Frontend und Backend, übernimmt die Middleware. Man kann sie als eine Art "Überstzer" zwischen Wunsch und Ergebnis verstehen. (Auch hier bezieht sich die Erklärung nur auf ein Datenbanksystem und seiner Anwendung. Allgemeiner ist das weitaus komplexer: https://de.wikipedia.org/wiki/Middleware)
So, warum beschreibe ich diesen ganzen Blubb, den keiner lesen will? Weil wir alle Excel immer wieder als Frontend, Middleware und Backend als einen Monoliten vergewaltigen, wann immer wir von einer "Datenbank" in Excel sprechen. Excel ist dann eben alles auf einmal. Wie gesagt, Excel kann durchaus so verwendet werden. Es sollte aber jedem bewusst sein, was damit zusammen hängt.
Backend in Excel:
Zumeist eine Tabelle, in der die Datensätze gespeichert sind, auf die zugegriffen werden soll. Hier findet oft mehrfache Datenhaltung statt, was für kleinere Projekte meistens funktioniert.
Middleware in Excel:
Das Makro oder die Formeln, womit auf den Datenbestand aus dem Backend zugegriffen wird, um eine Auswahl zurückzuliefern.
Frontend in Excel:
Eine UF oder eine Tabelle, in der die zurückgelieferten Daten angezeigt werden, die durch die Middleware ermittelt wurden
Funfakt:
Das Frontend dient sehr oft auch zur Datenerfassung. Damit wird es zur direkten (einseitigen) Schnittstelle zum Backend. Es ergibt sich also eine Art Kreislauf ;-)
Viele Grüße,
Zwenn

Nachdem ich in der Antwort an Zwenn von 1000 Datensätzen gelesen habe, musste ich schmunzeln. Als Excel Profi solltest du wohl ein Gefühl dafür haben was Excel heute an Berechnungszeiten für ein paar 10Tausend Datensätze hat!

Beliebteste Forumthreads (12 Monate)

11 Beiträge zum Forumthread Beiträge zu diesem Forumthread

VBA Beispiele zu verwandten Themen

Beliebteste Forumthreads (12 Monate)

Beliebteste Forumthreads (12 Monate)

11
Beiträge zum Forumthread

Beiträge zu diesem Forumthread