Also ich finde, man kann erstmal niemand vorwerfen, dass er das System nutzt (und dabei überfordert bzw. nicht optimal arbeitet).
Und diese Dataset Klamotten und die datensensitiven Komponenten sind ja immerhin ein Teil der Erfolgsgeschichte. Warum soll ich mit Delphi ein
RAD Tool einsetzen, mit dem ich aber lieber nicht
RAD Entwicklung mache, sondern die
DB schone?
Es gibt eine Geschichte -ich weiß nicht, ob sie stimmt- von einem Deutschen LKW Hersteller in Indien, wo ständig die Wagen zusammengebrochen sind und die Kunden sich beschwert haben. Der Hersteller hat gesagt, Ihr habt den Wagen überladen, das ist gegen die Nutzungs- und Garantiebestimmungen. Und die Kunden haben gesagt: Ich habe den Wagen einfach nur voll geladen.
Da der Hersteller in diesem Markt Fuß fassen wollte, hat er begonnen, seine LKW stärker auszulegen.
Mir ist ehrlich gesagt nicht klar gewesen, dass es so drastische Unterschiede gibt zwischen den System. Zu Delphizeiten habe ich mit Oracle gearbeitet. Nun arbeite ich viel mit Postgres, das sich angeblich ähnlich (schlecht) schlägt, wie Firebird. Das Phänomen ist mir aber in Webprojekten mit Postgres noch nicht aufgefallen.
Die Frage wäre doch nun, wie man dieses Manko aus Datenbanksicht erklären und ausbessern kann, ohne dabei alles umzukrempeln (in den Client Programmen). Denn das ist ja in vielen Fällen clientseitig offenbar aussichtslos (Aufwand).
Und es sind ja auch schon gute Punkte genannt worden.
Wieso nimmt Firebird sich nicht den verfügbaren Hauptspeicher, so dreist wie es
MSSQL macht?! Es gibt sicher nichts schnelleres, als alles was geht im Hauptspeicher zu puffern! Vielleicht weil
FB auch eine süße, kleine embedded
DB ist und das einfach in den Köpfen der Entwickler rumwabert? Welches Feature macht da den Unterschied?
Wieso macht es Postgres nicht? Die Systeme laufen standardmäßig auch auf Raspy & Co und das ist eine Hardwareausrüstung, die vor 20 Jahren noch Desktop/Server Niveau war, heute ein Witz für Server. Teuren Speicher nahm man sich nicht einfach so. Aber, Speicher ist nicht mehr teuer. Warum nicht mal die Schleusentore öffnen? Das großzügiger zu handhaben dürfte doch nicht so ein Riesenfeature sein.
Ganz klar, ich bin nicht dafür, stumpf seinen inperformanten Standard Code abzuliefern, im Gegenteil. An vielen Stellen muss man halt erstmal drauf kommen, wie es besser gehen könnte. Dabei helfen solche Threads ja vielleicht.
Aber ich sag auch:
Wenn man von Delphi Entwicklern fordert, dass sie endlich mal ihre Hausaufgaben machen, dann fordert man das doch am besten auch von den Programmieren der Datenbank oder?