Menü
Avatar von Exxtreme2
  • Exxtreme2

mehr als 1000 Beiträge seit 18.10.2008

Re: kein Wunder - die geben nur buzzwords von sich und wollen damit reich werden

Bitschnipser schrieb am 12.06.2019 20:18:

Hängt ein bisschen davon ab, was der macht.
Ich habe auch schon Sachen erlebt, wo der Nachtlauf doch zu langsam wurde und man eben nicht einfach so einen billigen Zweitserver danebenstellen konnte, sondern man musste die DB-Queries selber optimieren. Womit man dann DB-abhängig wurde.
Wobei das eher 1000 als 100 MA waren, so gesehen: Ja, es ist auch eine Frage dessen, wie weit man skalieren muss.
Aber wenn dein 100-MA-KMU auf 1000 MA skalieren muss, wird er mit der DB Schwierigkeiten kriegen. Was dann Leuten wie dir und mir die Frühstücksbrötchen bezahlt, man soll also nicht zu laut klagen - aber ideal ist das halt nicht.

Ja, das Hinstellen eines Zweitservers ist tatsächlich ein Vorteil von nicht-konsistenten Datenbanken. Muss man halt wissen ob man das braucht oder nicht.

Bitschnipser schrieb am 12.06.2019 20:18:

Nein, überhaupt nicht. Der eine ändert die Adresse und der andere die Umsatzstatistik.

Also ist die Umsatzstatistik in der gleichen Tabelle wie die Adresse?

Bitschnipser schrieb am 12.06.2019 20:18:

Nach drei bis fünf Jahren kannst du das mit dem guten Modell einfach vergessen. Da ist das Modell dann nicht mehr anpassbar.

Kommt drauf an mit was man entwickelt. Wirft man das SQL direkt gegen die DB dann wird es sehr schnell unwartbar, ja. Entwickelt man aber mit JPA Criteria API oder JOOQ oder ähnlichem dann kann man die Typsicherheit von Java nutzen. Und dann wird das nicht unwartbar.

Bitschnipser schrieb am 12.06.2019 20:18:

Natürlich, aber das sollte man sowieso.
Man muss ja die Gelegenheit haben, Fehler zu korrigieren; d.h. für die DB mag die Transaktion ja durch sein, aber das Geschäft muss die geschäftliche Transaktion immer noch rückabwickeln bzw. korrigieren können.
D.h. wenn man sich die Abläufe in den Geschäften anschaut, sind die alle, alle, alle auf eventual consistency ausgelegt (schließlich hat man in einer Firma mit Außenstellen auch genau die gleichen Probleme einer verteilten Datenhaltung, vor 50 Jahren ging das halt mit Papier und Kurier, aber die Probleme waren dieselben). Wenn man in der Software die Geschäftsprozesse mit Eventual Consistency abbildet, ist man dann sogar näher an den realen Prozessen dran als mit ACID (das ist natürlich nur tendenziell ein Vorteil, aber es ist einer).

Die Frage ist halt wie oft man korrigieren muss und ob man dafür jemanden einstellen muss weil man plötzlich viel mehr Korrekturbedarf hat. Es ist aber auch der umgekehrte Fall möglich: man nimmt die Fehler inkauf und bietet dem Kunden 10 € Entschädigung oder so weil eine Bestellung nach hinten losgegangen ist. Dafür geniesst man die Vorteile von nicht-konsistenten Datenbanken. Man muss beides gegeneinander abwägen. Bei Konsumgütern ist das evtl. viel günstiger, bei rechtlichen Dingen oder gar wenn Menschenleben davon abhängen dann kann eine konsistente ACID-Datenbank die viel bessere Lösung sein.

Bitschnipser schrieb am 12.06.2019 20:18:

Und genau das brauch ich ja im manuellen Geschäftsleben auch.

Ja, deshalb automatisiert man.

Bitschnipser schrieb am 12.06.2019 20:18:

Und wenn meine ACID-DB spinnt, weil der Administrator auf den falschen Knopf gedrückt hat oder der Entwickler einen Bug drin hat und die Nested Transaction gar nicht stattfindet, dann fällt das System auf die Schnauze.
Perfiderweise nur dann, wenn irgendwelche ungewöhnlichen Dinge laufen, dann kommt das nämlich immer dann obendrauf, wenn man es sowieso nicht brauchen kann.

Ja, kann passieren. Die Frage ist wie oft das vorkommt, dass ein Administrator die DB zersemmelt. Und das kann bei nicht-konsistenten Datenbanken auch passieren.

Bitschnipser schrieb am 12.06.2019 20:18:

(Ein Stück weit steckt hier auch die Chaos-Monkey-Philosophie drin: Wenn Ausfälle so selten sind, dass der Entwickler die nie erlebt, dann programmiert er auch nicht für die, und dann bricht alles gleichzeitig zusammen, wenn man doch noch einen Ausfall hat; hat man ein System, in dem man notfalls täglich einen Teilausfall provoziert, programmieren die Entwickler ganz anders, viel defensiver, und es kommt ein insgesamt wesentlich robusteres System heraus.)

Ja, ist ein gutes Beispiel. Oder die unsinkbare Titanic. Deshalb gibt es auch so einen schönen Aphorismus: mache deine Systeme sicher aber rede ja nicht darüber.

Bitschnipser schrieb am 12.06.2019 20:18:

Intuition ist arg subjektiv.
Obendrein stark von den Erfahrungen abhängig.
Ich hab noch nie einen Entwickler gesehen, der seine Transaktionen in der Software von selbst wiederholbar gestaltet hat (was man z.B. bei Oracle tun muss, weil da jede Transaktion aufgrund von technischen Interna der DB fehlschlagen kann - das passiert aber erst, wenn die DB ernsthaft Last hat, also produktiv läuft, beim Testen erlebt man das nicht.)

Ich habe sehr viel direkt mit Benutzern von Software zu tun und weiss wie die ticken. Sie erwarten, dass wenn sie Daten eingegeben haben, dass die dann im System drin sind. Wenn die Daten aber nicht überall sichtbar sind dann glauben sie durchaus, dass die EDV kaputt ist.

Grüße

Bewerten
- +
Anzeige