Synopse Open Source

To be more specific:

SQlite3, MySQL, PostgreSQL, MSSQL 2008 or NexusDB handle INSERT statements with multiple VALUES, in the following SQL-92 standard syntax, using parameters:

INSERT INTO TABLE (column-a, [column-b, ...])
VALUES ('value-1a', ['value-1b', ...]),
('value-2a', ['value-2b', ...]),
...

Oracle implements the weird but similar syntax (note the mandatory SELECT at the end):

INSERT ALL
INTO phone_book VALUES ('John Doe', '555-1212')
INTO phone_book VALUES ('Peter Doe', '555-2323')
SELECT * FROM DUAL;

Firebird implements its own syntax:

execute block
as
begin
INSERT INTO phone_book VALUES ('John Doe', '555-1212');
INSERT INTO phone_book VALUES ('Peter Doe', '555-2323');
end

As a result, some engines show a nice speed boost when used in BATCH.
Even SQLite3 is faster when used as external engine, in respect to direct execution, in respect to direct execution of individual prepared statements in loop! 

Here are some insertion results, to compare with the previous benchmark, which did not include these enhancements:

This feature is at ORM level, so it benefits to any external database library.
Of course, if a given library has a better option (e.g. our direct Oracle or FireDAC array binding), it is used instead.

You can note that we included access to Firebird embedded via ODBC, using the official driver.
And also SQLite3 access via ODBC, using this nice full-featured BSD licensed driver.
Sounds like a not so optimized solution, e.g. in respect to ZDBC/ZEOS direct connection.
But nice show case of ODBC connection with mORMot.

Reading speed is not affected by this modification, so we won't publish new data here.
Note that now our native access to external databases outperforms any third-party drivers, with the only exception of Firebird, which is still most efficiently accessed via FireDAC.
The SAD 1.18 pdf includes the latest benchmark.

If you want to use a map/reduce algorithm in your application, or the DDD's Unit Of Work pattern, in addition to ORM data access, all those enhancements may speed up a lot your process. Reading and writing huge amount of data has never been so fast and easy: you may even be tempted to replace stored-procedure process by high-level code implemented in your Domain service. N-tier separation would benefit from it.

Feedback is welcome on our forum, as usual.