Redundant Information
Find the English version below
Hi ,
“Nach dem Import packen wir das File aus und lesen die Meta-Informationen”
“Und wo schreiben wir sie rein”
“Diese Information wird in unterschiedlichen Datenbanken abgelegt. Die Path Information wird auf allen Service Datenbanken verteilt, damit diese wissen wie sie auf die Files zugreifen. Andere Daten legen wir in die System-Datenbank und in jede Tenant-Datenbank.”
Klingt das für dich normal?
Sollte es nicht.
Was wir hier erleben ist Informationsduplizierung.
“Aber Marcus, warum ist das denn so schlimm? Wir brauchen die Information halt an unterschiedlichen stellen.”
Ja. Stimmt. Die gleiche Information wird an mehreren Stellen benötigt.
Das ist meistens der Fall.
Wenn wir uns innerhalb einer Applikation befinden, dann kommen wir nicht auf die Idee für jedes Feature neue Tabellen zu erstellen.
Natürlich bauen wir eine Datenstruktur, die für alle Features funktioniert.
Und warum machen wir das?
Wir wollen die Applikation leicht verändern.
Wenn alle Features den gleichen Datensatz verwenden, dann können wir ihn zentral verändern.
Es wäre auch eigenartig, wenn wir den Preis eines Buches verändern und dieser nur im Detail-View angezeigt wird.
Natürlich soll er auch in den Suchergebnissen angezeigt werden.
Die redundante Ablage der gleiche Information ist ein Einfalltor für Bugs.
Es macht die Applikation schwer wartbar.
Eine Änderung der Logik muss an allen Stellen, an allen Services, in allen Datenbanken vorgenommen werden.
Kaum Einer kann alle Stellen auf Dauer überblicken.
Deswegen ist es so wichtig, dass wir immer nur eine Wahrheit haben.
Das gilt auch für Invertierbare Transformationen.
Wenn wir zum Beispiel einen Onlineshop betreiben:
Wir wollen den Bruttopreis eines Produkts berechnen. Der Bruttopreis eines Produkts ist der Nettopreis * Mehrwertsteuer. Der Bruttopreis ist direkt mit dem Nettopreis verknüpft. Er kann jederzeit aus diesem berechnet werden. Damit ist er keine neue Information. Deswegen brauchst du nur den Nettopreis speichern. ****
Der Bruttopreis ist lediglich eine Transformation der vorhandenen Daten.
Wenn du das nächste Mal an deinem Datenschema arbeitest, überlege, ob du duplizierte Informationen speichern möchtest. Und vermeide es!
Rule the Backend,
~ Marcus
Hi ,
“After importing, we unpack the file and read the meta-information.”
“And where do we write it?”
“This information is stored in different databases. The path information is distributed across all service databases so that they know how to access the files. Other data is stored in the system database and in each tenant database.”
Does that sound normal to you?
It shouldn't.
What we are experiencing here is information duplication.
“But Marcus, why is that so bad? We just need the information in different places.”
Yes. True. The same information is required in multiple places.
That's usually the case.
When we are inside an application, we don't think of creating new tables for each feature.
Of course, we build a data structure that works for all features.
And why do we do that?
We want to easily modify the application.
If all features use the same dataset, then we can change it centrally.
It would also be strange if we changed the price of a book and it only appears in the detail view.
Of course, it should also be displayed in the search results.
Redundant storage of the same information is a gateway for bugs.
It makes the application hard to maintain.
A change in logic must be made at all points, on all services, in all databases.
Hardly anyone can keep track of all places in the long run.
That's why it's so important that we always have only one truth.
This also applies to invertible transformations.
For example, if we run an online store:
We want to calculate the gross price of a product. The gross price of a product is the net price * value added tax. The gross price is directly linked to the net price. It can be calculated from it at any time. So it's not new information. That's why you only need to store the net price.
The gross price is just a transformation of the existing data.
The next time you work on your data schema, consider whether you want to store duplicated information. And avoid it!
Rule the Backend,
~ Marcus