The results will vary between specific relational database systems, their configurations, hardware and OS used, the specifics of the test, etc. If you do a search online to look for benchmark comparisons between various systems, you'll find endless critique on the benchmarks themselves, even when those doing the benchmarks try to be as objective as they can.Originally Posted by Will1
For all we know if you do the test on your hardware, it will be twice as fast as ADAM... or maybe it will take several seconds. For example, using the same modified shell script, I get a wall clock time of under 1.6s for 50000 rows, i.e., twice as many rows was not twice as slow.Originally Posted by Will1
Again, the results will vary between specific relational database systems, their configurations, hardware and OS used, the specifics of the test, etc. The notion of "512 byte rows" also does not quite apply, e.g., unless otherwise specified, SQLite3 has a rowid column for each table. This column would be indexed, possibly requiring additional space beyond simple storage of an integer, but it means extremely fast row retrieval by rowid. Then there is likely to be other meta-data concerning tables, columns and specific fields, along with the various structures like B-tree that constitute the database itself, things that cater to much more than just insertions into the database. In my case, I get a 55 MB database file, but a little experimenting shows that the storage used is not linear, e.g., changing the first argument to the shell script to 250 reduces the size to just 50 MB, but changing it to 240 reduces it to 25 MB. Hence, it looks easy to compare: 26 MB versus 55 MB (and maybe versus 24.4 MB as a baseline for 50000 * 512 B), but in reality it would be naive since databases are used for much more than just insertion of records consisting of 512 byte strings.Originally Posted by Will1
Agreed. It is unlikely that those around here who do have the particular expertise to help you will be inclined to do so given that you don't seem to have convinced anyone here that what you claim of ADAM is indeed accurate and worth the effort. I suggest that instead of dismissing what is current, you actually take time to experiment with them (and not just insertions, but the whole hog, e.g., retrieval, updating and deletions, and actually making use of foreign keys). Do not just look at relational database systems in current use, but also try out database systems with other approaches (particularly key-value stores).Originally Posted by Will1