Zitat von
IBExpert:
Ohne das genauer zu beleuchten kann man immer noch an diversen Schrauben drehen, es gibt auch bei firebird nicht nur cache buffers, sondern auch sort memory, sort block size etc.
Und solange man nicht weiß an welchen Schrauben gedreht wurde sind solche Statistiken mit Vorsicht zu genießen. Ich erinnere nur an den Pet-Shop welche für sowas mißbraucht wurde um zu zeigen das .NET oder doch JAVA schneller und besser ist.
Zitat von
IBExpert:
Es geht auch nicht immer darum ob dies oder das die beste Plattform ist, sondern ob man mit dem eigenen Businessmodell und den eigenen Programmierwerkzeugen und Kenntnissen etwas konkurrenzfähiges auf die Beine stellen kann.
FULL ACK. Deshalb habe ich ja auch keine
DB als die geeignete dargestellt sondern mehrer möglich aufgelistst.
Zitat von
IBExpert:
Aus meiner Sicht ist eine plattformübergreifende Implementation aber immer schwieriger,
Ja. Der Basisimplementierungen sind aufwendiger. Wenn man aber mal die
DB-Abhänigigkeit in eine
Unit für jede
DB gekaspelt hat ist es nicht mehr so schlimm.
Zitat von
IBExpert:
insbesondere wenn es um große Datenmengen geht. Wenn man weiss das externe Appserver zum Beispiel ca maximal 2000 bis 3000 Datensätze pro Sekunde verarbeiten können, intern jedoch in Stored Procedures auf gleicher Hardware durchaus Werte von 50000 möglich sind (zumindest bei Firebird),
Solche dinke stehen einen mit der passenden Abstraktion immer noch offen. Bisher reicht aber aktuell Prepared-Statemens + "Statement-Cache" aus.
Zitat von
IBExpert:
spricht schon so manches dafür, sich auf wenige plattformen festzulegen.
Wenn man dafür einen bestimmten Prozentsatz der Kunden verliert weil diese unbedingt nicht noch eine
DB haben wollen ...
Zitat von
IBExpert:
Plattformübergreifend kann man nur das nutzen was alle können. Das ist immer ein Kompromiss und der geht fast immer zu Lasten der Performance.
Oder es ist Aufwendiger für alle
DB's optimierungen zu finden.