AW: Interbase
Zitat:
Ich hätte ein ungutes Gefühl wenn Meine DB so etwas problemlos schluckt. Gruß K-H |
AW: Interbase
Hallo,
IB6 hatte damit kein Problem ... |
AW: Interbase
Das ist ja das Problem, wenn eine DB mit sowas kein Problem hat.
Denn es ist schlicht nicht eindeutig. Den Vogel schießt da ja mysql ab. Zum Glück gibt es hier seit einigen Versionen die Strict Einstellungen für den ganzen Schrott, den mysql sich in jungen Jahren da geleistet hat. Damit hat man dann die Chance, sein System wasserdicht zu machen. Natürlich ist es im Nachhinein eine Menge Arbeit und Spaß macht es auch keinen. Aber noch weniger Spaß macht sicher die Suche nach Fehlern, die dadurch entstehen. Unstimmigkeiten in Reports, mal so mal so Ergebnisse, mir graut. Nach wie vor ein Grund für mich, mysql nur zum Spielen anzufassen. |
AW: Interbase
Nun denn, dann einfach mal für jeden reproduzierbare Resultate (erst mal single
threaded, aber schon markant): In jeder IBExpert Version (auch in der Personal Edition) ist im Demo DB Pfad ein Script, das so auch mit Interbase funktioniert. Ob man das über IBExpert oder isql oder sonstwie ausführt, macht keinen Unterschied. Beide Datenbanken werden mit 16k pagesize angelegt (8k machte bei beiden keinen Vorteil). Wenn die DB fertig ist, dann wird über IBExpert - Services - Database Properties oder gfix der cache buffer auf 5000 gesetzt, so das der Cache ausreichend groß sein sollte (was die geringen Zahlen als Ergebnisse von reads und writes auch so bestätigen). Anschliessend disconnect und reconnect damit die buffers gesetzt sind. In beiden Datenbanken wird der jeweilige Client für 32 Bit eingesetzt (fbclient aus firebird 3.0.2 und gds32.dll aus dem installierten Paket). Der Test lief mit IBExpert, lässt sich aber auch mit der jeweiligen isql Version ausführen Beide DB Server sind 64 Bit Version auf identischer Hardware/Windows 10 Version (firebird Version 3.0.2 bzw. Interbase 2017 Developer Edition 13.0.0.129) Damit der Test einfach reproduzierbar ist, wird nun zunächst einfach mal jeweils 3 mal die SP initall gestartet mit dem parameter 10000 und danach jeweils disconnect/connect gemacht (weil beim ersten durchlauf noch keine Daten gelöscht werden müssen). Wenn das durch ist, dann startet man nun initall mit 10000 auf beiden Datenbanken, später dann noch mal 3 mal zum Auwärmen mit 100000 10000 erzeugt ca. 910000 individuelle insert/update/delete/select statements 100000 erzeugt ca. 9,1 Mio individuelle insert/update/delete/select statements Ergebnisse Interbase 10000 9,36 Sekunden Firebird 10000 4,11 Sekunden Interbase 100000 160,33 Sekunden Firebird 100000 57,63 Sekunden (ohne Statistik, aber mit 1 mio als param wird die db ca 1.3 GB groß) Interbase 1000000 37 Minuten Firebird 1000000 12 Minuten Unter ".. kann da FB noch mithalten" versteh ich da was völlig anderes .... Interbase braucht bei den meisten mir bekannten mehr oder weniger komplexeren Operationen 2-10 mal länger als Firebird (und ich rede da auch multithreaded nicht von der begrenzt vorteilhaften classic/superclassic version auf lahmen Festplatten und wir haben Firebird verschiedensten Hardware- und Userzahlkonfigurationen da im Einsatz ). ich würde mich freuen, wenn du das mit reproduzierbaren Beispielen widerlegen könntest, die nicht nur auf Inkompatibilitäten basieren. Zeig mir irgendwas, das Interbase schneller kann. Ich glaub auch keineswegs, das das irgendwie an der Developer Edition liegen sollte, falls das das Argument wäre, weil gleichartige Ergebnisse auch bei Kunden mit lizensierten Interbase Versionen mit reichlich cores identische Verhältnisse ergab. Query Statistiken aus IBExpert (die leichten Abweichungen der Operation liegen an der Random Funktion)
Code:
Anfang Interbase 2017 10000 35169 record(s) was(were) updated in INVENTORY 10000 record(s) was(were) updated in ORDERS 10000 record(s) was(were) deleted from CUSTOMER 10000 record(s) was(were) deleted from INVENTORY 10000 record(s) was(were) deleted from ORDERS 10000 record(s) was(were) deleted from PRODUCT 34993 record(s) was(were) deleted from ORDERLINE 10000 record(s) was(were) inserted into CUSTOMER 10000 record(s) was(were) inserted into INVENTORY 10000 record(s) was(were) inserted into ORDERS 10000 record(s) was(were) inserted into PRODUCT 35169 record(s) was(were) inserted into ORDERLINE ------ Performance info ------ Prepare time = 0ms Execute time = 9s 359ms Current memory = 32.743.344 Max memory = 35.797.280 Memory buffers = 1.783 Reads from disk to cache = 790 Writes from cache to disk = 51 Fetches from cache = 4.851.962 100000 349393 record(s) was(were) updated in INVENTORY 100000 record(s) was(were) updated in ORDERS 100000 record(s) was(were) deleted from CUSTOMER 100000 record(s) was(were) deleted from INVENTORY 100000 record(s) was(were) deleted from ORDERS 100000 record(s) was(were) deleted from PRODUCT 350371 record(s) was(were) deleted from ORDERLINE 100000 record(s) was(were) inserted into CUSTOMER 100000 record(s) was(were) inserted into INVENTORY 100000 record(s) was(were) inserted into ORDERS 100000 record(s) was(were) inserted into PRODUCT 349393 record(s) was(were) inserted into ORDERLINE ------ Performance info ------ Prepare time = 0ms Execute time = 2m 40s 328ms Current memory = 89.204.944 Max memory = 89.225.424 Memory buffers = 5.000 Reads from disk to cache = 40.517 Writes from cache to disk = 3.947 Fetches from cache = 49.142.098 Ende Interbase 2017 Anfang Firebird 3.0.2 10000 34953 record(s) was(were) updated in INVENTORY 10000 record(s) was(were) updated in ORDERS 10000 record(s) was(were) deleted from CUSTOMER 10000 record(s) was(were) deleted from INVENTORY 35007 record(s) was(were) deleted from ORDERLINE 10000 record(s) was(were) deleted from ORDERS 10000 record(s) was(were) deleted from PRODUCT 10000 record(s) was(were) inserted into CUSTOMER 10000 record(s) was(were) inserted into INVENTORY 34953 record(s) was(were) inserted into ORDERLINE 10000 record(s) was(were) inserted into ORDERS 10000 record(s) was(were) inserted into PRODUCT ------ Performance info ------ Prepare time = 0ms Execute time = 4s 109ms Current memory = 88.583.408 Max memory = 89.313.520 Memory buffers = 5.000 Reads from disk to cache = 1.071 Writes from cache to disk = 18 Fetches from cache = 3.917.798 100000 350293 record(s) was(were) updated in INVENTORY 100000 record(s) was(were) updated in ORDERS 100000 record(s) was(were) deleted from CUSTOMER 100000 record(s) was(were) deleted from INVENTORY 349696 record(s) was(were) deleted from ORDERLINE 100000 record(s) was(were) deleted from ORDERS 100000 record(s) was(were) deleted from PRODUCT 100000 record(s) was(were) inserted into CUSTOMER 100000 record(s) was(were) inserted into INVENTORY 350293 record(s) was(were) inserted into ORDERLINE 100000 record(s) was(were) inserted into ORDERS 100000 record(s) was(were) inserted into PRODUCT ------ Performance info ------ Prepare time = 0ms Execute time = 57s 625ms Current memory = 89.840.264 Max memory = 92.460.528 Memory buffers = 5.000 Reads from disk to cache = 26.224 Writes from cache to disk = 19.499 Fetches from cache = 52.106.099 Ende Firebird 3.0.2 |
AW: Interbase
Firebird installiert (3.0.2), IBExpert installiert.
DB erzeugt..... INITALL aufgerufen:
Code:
(Hat der Editor von IBExperts noch nichtmal eine Zeilennummerierung?!?!?)
validation error for column "CUSTOMER"."FIRSTNAME", value "*** null ***".
At procedure 'INITALL' line: 106, col: 5. |
AW: Interbase
Zitat:
wie wäre es mit (Hat der Formulardesigner von Delphi nicht nicht einmal ein Undo?!?!?!?) Ist auch nicht besser oder? Von mir aus kann der Thread geschlossen werden, bevor das hier noch ausartet. Habe mich für Firebird entschieden, es geht um ca 70 Clients und es werden ziemlich sicher noch mehr. Das wird für den Einsatzzweck zu teuer. Das ist aber eine Entscheidung für diesen speziellen Fall und sollte nicht als allgemeine Aussage gewertet werden! Danke an alle die geantwortet haben. Zitat:
|
AW: Interbase
Zitat:
selber entscheiden ob man das haben möchte oder nicht. http://ibexpert.net/ibe/index.php?n=...#EditorOptions Der Null fehler deutet darauf hin, das du keinen Parameter an die SP übergeben hast, dann weiss die nicht, wie groß die db werden soll. Nimm zB 10000 als Anfang Und zur Zeilennummer: Im Default arbeitet der SP Editor im Lazy mode und zeigt nur Zeilennummern im Body an, daher würde die von FB generierte Fehlernummer woanders hinzeigen. Um die übereinstimmen zu lassen, setze hier statt lazy den Standard mode http://ibexpert.net/ibe/index.php?n=...2900#ProcEdOpt Und es ist ja nun keineswegs so das Delphi schon immer Zeilennummern konnte, zumindest bis inkl V7 war das gar nicht möglich, das nur so am Rande ;-) Während der Forentage bin ich leider im Amerika, würde aber wenn Daniel es technisch ermöglichen kann, gerne die Session mit Matthias auch remote machen. Ich hab da wo ich an dem Samstag bin, sehr gutes Internet und über pcvisit können wir problemlos auf auf den Bildschirmen zwischen Hamburg und USA für alle sichtbar umschalten. |
AW: Interbase
Das fände ich super!!!!
|
AW: Interbase
Zitat:
Gruß K-H |
AW: Interbase
Zitat:
Das ein Editor (ich weiß um die Problematik der BLRs) eine Zeilennummerierung haben sollte (was er ja wohl auch hat), ist kein ungewöhnlicher Anspruch.... |
Alle Zeitangaben in WEZ +1. Es ist jetzt 13:40 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz