Re: Robust single file database
marek jedlinski
suggestion. If all you need is storage, don't use a database, especially if
you haven't used them before. Any robust DB you choose will be anything
between complex and impenetrable (or at least it will appear so to a
database novice). And it will add overhead you don't need if you only use
it to read and write streams.
DISqlite3 is lightweight and very fast, but I found coding for it rather
unintuitive and slow-going, weaving the SQL all the way. NexusDB (note
there is a free embedded version) will be easier to use, since it gives you
a TDataSet, so any Delphi db tutorial will help, but it is not exactly
simple either and it will add a lot of code to your application that will
never get used.
Also, with Nexus, each table is a separate file. This may be OK if you only
need one, but from your users' point of view the "document" they create
will not be a file, but a folder (which is Nexus's database). If your users
will want to backup, copy, zip or email their data files, dealing with
folders makes it somewhat less convenient than dealing with single files.
It may also invite users to put their own stuff into those folders, or nest
those "document" folders inside one another, and that could spell trouble.
These considerations may not apply to your project, of course.
My advice would be to use a "compound file" solution - essentially a
filesystem within a a single physical file. After much trial I've settled
on SingleFileSystem from aidaim.com, which provides good performance, is
very simple to use (all procedures are analogs of Delphi's standard file
handling routines, so you can get going right away), and provides
compression and encryption if you need it.
On the flip side, I have just found out that SFS performance suffers if you
write lots of small pieces to a stream, rather than write the whole stream
in one go - especially if you enable compression. In this case the solution
is to write your little chunks of data to a memorystream, and then flush
the memorystream to SFS.
There is also a free, open-source compound file implementation - google for
GpStructuredStorage.pas by Primoz Gabrijelcic. It doesn't do encryption or
compression, and does not have all the functionality of SFS, but works
equally fine if all you need is reading and writing streams.
Another frequently mentioned compound file product is Solid File System
(www.eldos.com/solfs/). It's even more featureful than SFS (transactions,
stream metadata, etc.), but the price tag is... well, put down your coffee
before you go check it out :)
marek
--
No ads, no nags freeware: http://www.tranglos.com
Skype: tranglos GG: 5967086
On Tue, 9 Jan 2007 18:51:43 -0500, "Ian Roberts" <ianro...@nospam.com>
wrote:
>I am looking for an easy to use database engine that would allow one to
>store numerous objects in a database (using Blob fields) . Ideally, this
>database should be robust, able to support pretty large tables, be not too
>expensive and have a small footprint. Configuration should be pretty easy
>and ideally, this database should work without any DLL.
>
>I have tried disqlite3 which seems to fill all those conditions. But it is
>quite complicated to use (for an unsophisticated programmer like myself), so
>I am looking for an alternative.
>
>Any suggestion
>
>
Hannes Danzl[NDD]
Depending on what you mean with pretty large, keep in mind that lots of
machines out there are still running operating systems with limits on file
size. If your database has several large tables you will hit this boundary
quite soon. Another thing to remember is that lots of people still have no
means of backing up more than a DVD size of data. Again with large tables into
one file you'll hit that quite fast.
--
Hannes Danzl [NexusDB Developer]
Newsgroup archive at http://www.tamaracka.com/search.htm
LSW
> I am looking for an easy to use database engine that would allow one to
> store numerous objects in a database (using Blob fields) . Ideally, this
> and ideally, this database should work without any DLL.
>
> I have tried disqlite3 which seems to fill all those conditions. But it is
> quite complicated to use (for an unsophisticated programmer like myself), so
> I am looking for an alternative.
>
> Any suggestion
We've used FlashFiler for quite some time now:
http://sourceforge.net/projects/tpflashfiler
Haven't had any problems with it's robustness. It can be compiled into a
single exe, and works like a replacement for Delphi's TTable, TDataSet,
TQuery classes etc. We've had data logging databases running up to about
1 GB with no problems.
HTH,
--
Luke.
Ian Roberts
Bob D.
comes to open-source.
So NexusDB is the modern (but commercial) version of FlashFiler.
"LSW" <nos...@nospam.com> wrote in message
news:45a42bec$1...@newsgroups.borland.com...
Steve Forbes
I have used
a. (Jet) MSAccess via ODBC, it supports relatively large file sizes, and is
generally quite robust in single user mode, and
b. AbsoluteDB (www.componentace.com), has been very robust (never
experienced a data corruption, or index problem) but not used with huge
amounts of data
HTH
--
Best regards
Steve
"Bob D." <bo...@demo.it> wrote in message
news:45a42f6f$1...@newsgroups.borland.com...
Craig Clemans
Firebird, it's free! Single file database.
http://www.ibphoenix.com/ will get your started.
hth,
Craig Clemans
Delphi source code for accounting systems
www.ledgeraccounting.com
Tate Needham (FinalBuilder)
> Neither NexusDB nor FF are single file databases.
not quite true... NexusDB can have "child" tables, so you can have a
single file that contains multiple tables [FinalBuilder works in this way].
.t8
Steve Forbes
Oh, and I meant to mention Firebird as well
--
Best regards
Steve
"Tate Needham (FinalBuilder)" <ta...@finalbuilder.com> wrote in message
news:45a44f3b$1...@newsgroups.borland.com...
Renaud
We are using it in our company since years (100 clients PC + 2 web
servers connected on the same base 3Go, 4M records). Free, robust, easy
to setup and nearly no maintenance. I also use it with other apps
deployed at customers. The FBClient.dll is copied in the same directory
than the app exe, so nothing to install on client PC. I use IBObjects
(TDataSet compatible) but other access components are available.
Ian Roberts a écrit :
Ralf Junker - http://www.yunqa.de/delphi/
As the author of DISQLite3: I am sure that DISQLite3 meets all your
requirements: no DLL, less than 300 K footrpint, virtually no data limits,
encryption, excellent performance.
I also believe that DISQLite3 is not at all difficult to work with. However, I
am always looking for ideas to improve DISQLite3, especially the Demos and the
help.
I would therefore like to write a demo project targeted at your requirements
which I hope will give you and others an easier start with DISQLite3. If you let
me know your implementation details (types of objects, search indices, etc) by
e-mail, I should have something ready for you within a day or two.
Regards,
Ralf
---
The Delphi Inspiration
http://www.yunqa.de/delphi/
Falanga Alain
Hi Ralf,
Any samples (or component) for making concurrent writing in the same
SQLite DB with DISQLite morea easily than now (with handle status and
timeout) will be a great enhancement, and if those can be done in a
thread it will be ... amust :)
Cheers,
Alan
--
Ceci est une signature automatique de MesNews.
Site : http://www.mesnews.net
Ian Roberts
I have used DISQLite3 on anogher project and I'm glad I did. It was
amazingly fast and efficient. More than anything I have tested before and it
does have a small footprint (much smaller than alternative products). But
creating a database using DISQLite3, opening it, reading a value or changing
an existing one, are all procedures that require cryptic commands, very
different from what one use when working with other database engines in
Delphi.
I have done some tests comparing different products (i.e. EasyTable,
Accuracer, Absolute Database, Advantage). I wrote small benchmark of about
50 lines (creating a database, filling it with random data, browsing through
records, creating index, modifying data, filtering, etc. Almost the same
code was used for all 3 engines I tested (from 1 to 3 lines had to be
changed).
With DISQLite3, I would have to rewrite the full 50 lines, would probably
need 100 lines or more, and the resulting program would be difficult to
read. What you need is a VCL wrapper for your component, something that
would allow one to read a value using a command like:
AuthorS := Table1.FieldsByName('Author').AsString
rather than something like:
sqlite3_check(sqlite3_prepare(DB, PChar('SELECT "Author" FROM
"TableName" ;'), -1, @Stmt, nil), DB);
if Assigned(Stmt) then
if sqlite3_check(sqlite3_step(Stmt), DB) = SQLITE_ROW then
Result := sqlite3_column_str(Stmt, 0);
There may be a fastest way to do this, but the fact that I can't figure out
how is an indication of how difficult DISQLite3 can be.
You will find enclosed a simplified version of my basic test program (I
remove some redundant codes and timing of individual procedures). If you
want to write a simple DISQLite3 version, I would be glad to put it to the
test and report the results (based on my previous experience with DISQLite3,
I'm pretty confident your component will beat all the other programs in term
of speed).
For the benefit of other users, in my comparisons, Absolute Database was the
fastest single file database for creating, reading, writing, indexing and
filtering. A lot faster than EasyTable and Accuracer. It was almost as
fast and sometimes faster than Advantage on almost all operations except
for indexing. In this case Advantage is hard to beat, indexing 100,000 in
0.1 second compare to 25 seconds for Absolute and 69 seconds for EasyTable.
Unfortunately, Advantage is not a single file database system. BTW, another
benefit of Advantage is the size of the resulting files, a total of 4.5Mb
for Advantage (data table + index) but 13.7Mb for Absolute and even more for
EasyTable.
Is there other programs I should try? (beside Firebird)
Ian
Procedure TForm1.TestDatabase(Sender: TObject);
var
I: Integer;
S: string;
R: Double;
T1 : TDateTime;
begin
T1 := Now;
Randomize;
// Create the database
DB.Close;
DB.CreateDatabase;
if Table1.Exists then Table1.DeleteTable;
Table1.FieldDefs.Clear;
Table1.FieldDefs.Add('IdName', ftInteger, 0, False);
Table1.FieldDefs.Add('name', ftString, 20, False);
Table1.FieldDefs.Add('Random', ftFloat, 0, False);
Table1.CreateTable;
Table1.Open;
// Creating 100,000 records
for I := 1 to 100000 do begin
Table1.Append;
Table1.FieldByName('IdName').AsInteger := I;
Table1.FieldByName('Name').AsString := 'John ';
Table1.FieldByName('Random').AsFloat := Random * 1000;
Table1.Post;
end;
// Reading all floating point and string values
Table1.First;
repeat
R := Table1.FieldByName('Random').AsFloat;
S := Table1.FieldByName('Name').AsString;
Table1.Next;
until Table1.Eof;
// Creating an index on Name
Table1.Close;
Table1.RestructureIndexDefs.Add('First', 'Name', [], false, 'Name',
'Name');
Table1.RestructureTable;
Table1.Open;
Table1.IndexName := 'First';
// Filtering data
Table1.Filtered := False;
Table1.Filter := 'RANDOM < 100';
Table1.Filtered := True;
ShowMessage(FloatTostrF(Now-T1)*26*60*60,fffixed,10,2));
end;
Shane Stump
I would recommend you "make-them-a-reasonable-offer" if you decide to
buy it. The only reason I say that is that they run LARGE discounts off
@ various times of the year for most of their products.
Best Regards,
Shane
Ralf Junker - http://www.yunqa.de/delphi/
>Any samples (or component) for making concurrent writing in the same
>SQLite DB with DISQLite morea easily than now (with handle status and
>timeout) will be a great enhancement, and if those can be done in a
>thread it will be ... amust :)
I have contacted Alain via e-mail to talk about this in more detail.
Ralf Junker - http://www.yunqa.de/delphi/
>I have used DISQLite3 on anogher project and I'm glad I did. It was
>amazingly fast and efficient. More than anything I have tested before and it
>does have a small footprint (much smaller than alternative products). But
>creating a database using DISQLite3, opening it, reading a value or changing
>an existing one, are all procedures that require cryptic commands, very
>different from what one use when working with other database engines in
>Delphi.
You must be using an old version of DISQLite3. If you download the latest
version, you will find that it contains object wrappers as well as a TDataSet
descendant to simplify working with the engine:
* TDISQLite3DataBase
* TDISQLite3Statement
* TDISQLite3UniDirQuery
* TDISQLite3DataSetImporter
These components greatly help to simplify writing advanced database
applications, as shown some of the demo project. TDISQLite3UniDirQuery works
with DB-aware components, including TClientDataSet and report writers.
>I have done some tests comparing different products (i.e. EasyTable,
>Accuracer, Absolute Database, Advantage). I wrote small benchmark of about
>50 lines (creating a database, filling it with random data, browsing through
>records, creating index, modifying data, filtering, etc. Almost the same
>code was used for all 3 engines I tested (from 1 to 3 lines had to be
>changed).
>
>With DISQLite3, I would have to rewrite the full 50 lines, would probably
>need 100 lines or more, and the resulting program would be difficult to
>read.
DISQLite3 is different from other database products, but it is not more
difficult. Some operations are even easier (like adding indexes). The object
wrappers allow for well structured programs, small in size as well as in code: I
required 40 lines of code only (excluding comments) to rewrite your test
procedure for DISQLite3.
>What you need is a VCL wrapper for your component, something that
>would allow one to read a value using a command like:
>
> AuthorS := Table1.FieldsByName('Author').AsString
TDISQlite3UniDirQuery is your friend!
>You will find enclosed a simplified version of my basic test program (I
>remove some redundant codes and timing of individual procedures). If you
>want to write a simple DISQLite3 version, I would be glad to put it to the
>test and report the results (based on my previous experience with DISQLite3,
>I'm pretty confident your component will beat all the other programs in term
>of speed).
>
>For the benefit of other users, in my comparisons, Absolute Database was the
>fastest single file database for creating, reading, writing, indexing and
>filtering. A lot faster than EasyTable and Accuracer. It was almost as
>fast and sometimes faster than Advantage on almost all operations except
>for indexing. In this case Advantage is hard to beat, indexing 100,000 in
>0.1 second compare to 25 seconds for Absolute and 69 seconds for EasyTable.
>Unfortunately, Advantage is not a single file database system. BTW, another
>benefit of Advantage is the size of the resulting files, a total of 4.5Mb
>for Advantage (data table + index) but 13.7Mb for Absolute and even more for
>EasyTable.
Please find my adaptation to DISQLite3 below. I have added some explanations to
what might be unfamiliar to new users. The procedure compiles and runs fine with
the latest DISQLite3 from http://www.yunqa.de/delphi/. The resulting database
file is 3.8 MB in size with DISQLite3 Pro, and 4.0 MB with the Personal edition.
Performance also differs slightly in favour of DISQLite3 Pro.
I am looking forward for your timings.
Ralf
//------------------------------------------------------------------------------
procedure TForm1.Button1Click(Sender: TObject);
var
DB: TDISQLite3Database;
Stmt: TDISQLite3Statement;
i: Integer;
s: AnsiString;
r: Double;
t1: TDateTime;
begin
t1 := Now;
Randomize;
{ Notice: Since this test contains ASCII text data exclusively, the DISQLite3
UTF-8 interface is used to achieve best performance. Internally, all text
is still stored as Unicode. A WideString / UTF-16 interface is available
by appending ...16 to the relevant function calls.}
// Create the database
DB := TDISQLite3Database.Create(nil);
DB.DatabaseName := 'test.db3';
DB.CreateDatabase;
DB.Execute('CREATE TABLE t (IdName INTEGER, Name TEXT, Random REAL);');
// Creating 100,000 records
{ DISQLite3 easily handles 50000 inserts per second, but only about 60
transactions per second. Normally, DISQLite3 puts each insert into
a separate transaction, which then limits you to about 60 inserts per
second. By using StartTransaction ... Commit we can group multiple inserts
into the same transaction thus increasing insert rate.
Transactions are slow due to limitations of computer disk hardware. When
DISQLite3 writes to the disk, it has to stop and wait at a couple of places
for all of the data to actually be written to the disk surface. This is
necessary in case a power failure or OS crash occurs - so that the data can
be recovered. It is this stopping and waiting that takes so long.
Therefore we wrap the following bulk insert into a transaction for best
performance. }
DB.StartTransaction;
try
Stmt := DB.Prepare('INSERT INTO t VALUES (?, ?, ?);');
try
for i := 1 to 100000 do
begin
Stmt.bind_Int(1, i);
Stmt.bind_Str(2, 'John');
Stmt.bind_double(3, Random * 1000);
Stmt.Step;
Stmt.Reset;
end;
finally
Stmt.Free;
end;
finally
DB.Commit;
end;
// Reading all floating point and string values
{ Reading the database does not require a transaction for speedup. Only a
prepared statement and a simple while loop around Stmt.Step are needed. }
Stmt := DB.Prepare('SELECT Name, Random FROM t;');
try
while Stmt.Step = SQLITE_ROW do
begin
s := Stmt.Column_Str(0);
r := Stmt.Column_Double(1); // Warning can be ignored - this is just a
test!
end;
finally
Stmt.Free;
end;
// Creating an index on Name
{ DISQLite3 creates an index by just executing a single SQL command. }
DB.Execute('CREATE INDEX First ON t (Name);');
// Filtering data
{ DISQLite3 filters data using the SQL WHERE clause. It can be followd by
any expression, subquery, or user-defined function. The WHERE clause
will automatically use existing indexes to speed up performance.
Notice: There is no index defined for the "Random" column. }
Stmt := DB.Prepare('SELECT Name, Random FROM t WHERE Random < 100;');
try
{ What to do with the filtered data? }
finally
Stmt.Free;
end;
DB.Free;
ShowMessage(FloatToStrF((Now - t1) * 26 * 60 * 60, ffFixed, 10, 2));
end;
Ralf Junker - http://www.yunqa.de/delphi/
>I have contacted Alain via e-mail to talk about this in more detail.
My e-mail to your has been returned. Can you contact me instead?
Ian Roberts
application (it actually took so much time to browse through an table that
was indexed (more than an hour, while other took about a second). Even
without this test it ws pretty slow, much slower than Absolute Database.
Ian
"Shane Stump" <ShaneATStumpWare.com> wrote in message
news:45a5...@newsgroups.borland.com...
Shane Stump
database is NexusDB, I have used Accuracer in a couple of applications
with good success.
Best Regards,
Shane
Ian Roberts
You are right! I didn't had those components in the version I was using and
after upgrading, I must say that your component is easier to use, yet still
a little bit more complicated than the others. It is also not a good
candidate for BDE replacement because of its lack of support for db aware
controls (especially TDBGrid). I am thus still looking for a BDE
replacement creating single file.
However, I must say that my speed test confirm my impression that your
component is the fastest and also the one that produces the smallest
database file and has the smallest footprint. For those who are interested
in speed comparison here are some results I obtained on a pretty simple
test comparing (Absolute, Easy Table, Advantage Database and DISQLite3). I'm
not sure the table can be read easily so here are my conclusions. The
fastest programs were in descending order:
DISQLite3 - way faster than the others
ADS - pretty fast
Absolute Database - Fast
EasyTable - pretty slow (comparatively to others)
DISQLite3 and ADS also produced the smallest databases (I computed the total
size of the table and the index for ADS), and Absolute Database and
EasyTable created the largest ones (their index increased the database file
a lot).
I have contacted the makers of EasyTable. They claim their engine is pretty
fast, so I wish to leave them the opportunity to explain to me why they are
so slow in my test. (I sent them a copy of this test).
Ian
----------
Result table. Best viewed with courrier
ABS EASY ADS DISQLite3
Creating 100,000 records 10.7 53.0 5.6 1.05
Reading all doubles 0.4 20.4 0.7 0.1
Reading all strings 0.4 20.5 0.5 0.2
Create index 25.3 69.2 0.1 1.0
Reading doubles with index 0.9 51.1 1.3 0.2
Reading strings with index 0.9 50.1 1.0 0.2
Filter 1 of 10 records 0.0 1.7 0.0 0.0
Size of DB 13.7MB 14.4MB 4.5MB 4.0MB
jeffc
not a single file database, but it would be great to see the comparison
since its supposed to be a good performer as well and I always wondered
how it compared to DISQLite
--- posted by geoForum on http://delphi.newswhat.com
Ian Roberts
ago that DBISAM was pretty slow on indexing.
Ian
"jeffc" <nos...@hotmail.com> wrote in message
news:45a55ad1$1...@newsgroups.borland.com...
kh.af...@gmail.com
1-NexusDB
2-Firebird
Don't go for FlashFiler. It's dead, and its continued code base is
maintained as a professional product named NexusDB. It's fast,
reliable, and very capable, SQL 2003 compliant, with all the
encryption, add-in management and such. But it is not free and not
really single file. Also, its logical working structure is somehow
complicated.
Your connection method to the DB is limited. You have to use the
providers technology and you don't have much choice.
But the Add-In ability makes it VERY flexible.
Firebird is totally free, also very reliable, Fast, well maintained,
actively developed, and very simple to learn. It's SQL92 compliant and
simpler than most databases mentioned here.
Also, it has a huge community, with thousands of samples, demos, IDEs,
....
The most powerful and interesting ability of Firebird is that it comes
with an embedded server. You change the name of the client library DLL
in your application, and you do have a self running fully compatible
server. And it has a Read-Only mode for Databases deployed on CD's
(like Encyclopedias for example). Don't be afraid of the DLL. You have
nothing to do with it! Components deal with it, you just work with
Datasets :)
Also, you can use components like IBX, IBO and FIB to connect to the
DB.
You can use DBExpress with free drivers (UIB) also.
There is a .NET provider, OLEDB provider (It's not free), and even a
JDBC driver!
There are many IDEs for it.
And it is single file.
There are some other Databases, but they are not as promising as these
two DB servers for you. Some are expensive, some are complex, some are
not single file, ...
I've used both of these DBs, and almost all databases available:
MS SQL Server & MSDE (it's free edition), ORACLE from 8 to 10g, MYSQL,
PostGres, SQLLite, DBISAM, FlashFiler, ...
Not one of them came near Firebird and NexusDB for Light Duty Databases.
Robin
> Also, you can use components like IBX, IBO and FIB to connect to the
> DB.
> You can use DBExpress with free drivers (UIB) also.
> There is a .NET provider, OLEDB provider (It's not free), and even a
> JDBC driver!
I recommend FireBird too. I use it a lot for single file, no server
deployments.
It is worth mentioning that IBX, and some others, are really Interbase
drivers. There is 9/10ths of stuff all difference between Interbase 6
and Firebird 1.5 but the two are going their separate ways and may not
be compatable in the future.
That said, I am personally sticking with Firebird 1.5 and IBX :-) A
match made in heaven.
--
Robin.
Hannes Danzl[NDD]
> providers technology and you don't have much choice.
> But the Add-In ability makes it VERY flexible.
Not particularly sure what you mean. You can access NexusDB tables via Delphi
direct access using either TnxTable or SQL using TnxQuery. Alternatively you
can access it via ODBC or ADO.NET which pretty much allows access from any
other programming language and/or application.
Eivind Bakkestuen
> maintained as a professional product named NexusDB. It's fast,
Actually, the above is a common misconception. NexusDB is *not* a continued
FlashFiler codebase; NexusDB was rewritten from scratch because TurboPower
did not want to discuss licensing the FlashFiler 3 codebase to us.
However, that also means that we do not inherit any problems from
FlashFiler. I would not recommend FF for business use.
--
Eivind Bakkestuen
Nexus Database Systems Pty Ltd
Malcolm Cheyne
>its
> not a single file database, but it would be great to see the
> comparison
I would love to see how the NEW NEXUSDB V2.06 (about to be released)
compares in your speed tests. I know some people classify it as "not
a single file database", but with what I have read in various NG you
can have a SINGLE table composed of "child" tables. To me, this
qualifies as "single file" !!
Malcolm
Ivan Pastine
Hannes Danzl[NDD]
> Doesn't it put indexes and other stuff into separate files?
Not per default, you can if you want to. It creates some system tables but if
you don't use stored procedure or similar you won't need to ever copy them.
Chris
Daft question as there is no mention on your website of this, but does
DISQLite3 work with BCB6 or BDS2006 C++ personality?
Best regards
Chris F
Frans van Daalen
"Ian Roberts" <ianro...@nospam.com> wrote in message
news:45a55c55$1...@newsgroups.borland.com...
> I'll try to do this! But I remember when I made some tests several years
> ago that DBISAM was pretty slow on indexing.
>
years old ;-)
Ralf Junker - http://www.yunqa.de/delphi/
>Daft question as there is no mention on your website of this, but does
>DISQLite3 work with BCB6 or BDS2006 C++ personality?
DISQLite3 does not officially support C++ Builder, but some testing with BCB6
suggests that it installs, compiles, and runs just fine.
Package files to install the DISQLite3 components into the BCB6 IDE are
available from
http://www.yunqa.de/delphi/downloads/DISQLite3_C6.zip
Chris
Chris F
"Ralf Junker - http://www.yunqa.de/delphi/" <del...@yunqa.dot.de> wrote in
message news:cb8cq25u96ubnovbc...@4ax.com...
kh.af...@gmail.com
Hannes, don't get me wrong. :)
I meant a Delphi developer does not have much choice in connection
methods to Nexus.
ODBC is slow, .NET is not native code. If you want to use Nexus in
Delphi, you have to go for components provided with NexusDB. No other
choice AFAIK.
It'll be a good idea to add a DBExpress driver for NexusDB.
kh.af...@gmail.com
Didn't know that.
Thank you, and good job! :)
Hannes Danzl[NDD]
We had a DBExpress driver for V1 but only a handful of people ever used it, so
we decided to not go ahead for V2. It's at the end "just another" access
method for Delphi only with no real benefit performance or feature wise over
direct TDataset access. That said we of course know that it's much easier to
change DB if you are based on DBExpress...
Eivind Bakkestuen
As Hannes says, it didnt make the cut for v2 because of very few requests.
We will however be supporting the future changes CodeGear have hinted on for
the BDS data access.
Joe Hendricks
> We will however be supporting the future changes CodeGear have hinted on for
> the BDS data access.
Good!
That means I will finally get an ECO mapper for Nexus!
CodeGear is certainly making the required noise about ECO..
JoeH
Tony Pomfrett
I just did the first 4 tests using DBISAM 4.25 with the following results:
Creating 100,000 records 1.78s
Reading all doubles 0.46s
Reading all strings 0.47s
Create index on string field 0.85s
So it seems to compare well with ADS & DISQLite3
Tony.
=============================================================
Ian Roberts
Hard to say how it compares without using the exact same code I have used
and also without using the sample computer configuration as I did.
Can you send me your small DBISAM program to ianroberts2 at yahoo dot com or
send the code here on this list. One problem I have when trying to test
various BDE alternative is to learn how each BDE works, how your create a
database and a table. If you show me how you did it, I will be able to
confirm your results.
Ian
"Tony Pomfrett" <to...@aline.com.au> wrote in message
news:45a8...@newsgroups.borland.com...
Ian Roberts
is indeed fast, as fast or faster than ADS on reading/writing data . It is
however slower than ADS and DISQLite3 on indexing (but much faster than
Absolute Database and Easy Table).
I wrote to AidAim asking them whether there was a way to improve the
performance of EasyTable, but they never replied. On their web site, they
still have an old test showing that EasyTable is a lot faster than DBISAM
(version 2.09). My own tests suggest that for the tasks below, the latest
version of EasyTable if from 20 to 60 times slower than DBISAM. They offer
the full source of the testing program for each DB engine so maybe someone
should run this test on the latest version of all those programs.
BTW, those of you who would like me to add similar results to NexusDB or
Firebox, I suggest they write a small routine that creates a database and a
data table with 3 fields (integer, string20 and float). See my simplified
version of the testing program in another message of this thread. (You may
then send it to me a ianroberts2 at yahoo dot com).
Ian Roberts
Result table. Best viewed with courrier
ABS EASY ADS DISQL DBISAM
Creating 100,000 records 10.7 53.0 5.6 1.05 2.0
Reading all doubles 0.4 20.4 0.7 0.1 0.7
Reading all strings 0.4 20.5 0.7 0.2 0.7
Rewriting records 3.0 59.6 3.9 ? 2.0
Create index 25.3 69.2 0.1 1.0 3.5
Reading doubles with index 0.9 51.1 1.3 0.2 0.8
Reading strings with index 0.9 50.1 1.0 0.2 0.8
Rewriting records 26.6 133.4 4.8 ? 3.0
Filter 1 of 10 records 0.0 1.7 0.0 0.0 0.6
Size of DB 13.7MB 14.4MB 4.5MB 4.0MB 12.5Mb
"Tony Pomfrett" <to...@aline.com.au> wrote in message
news:45a8...@newsgroups.borland.com...
Tony Pomfrett
I did reply in this newsgroup to your previous post but it didn't get
through for some reason.
You probably need to be very familiar which each of the databases before
you can say you have gotten the best performance from them. Each would
have its own little quirks.
In the case of DBISAM, I used their utility program (DBSYS) to create
your test table. Then I used the reverse engineer feature to produce the
pascal code necessary to create and populate the table. Then I modified
that code to do your other tests. Unfortunately, I did not save that code.
Tony.
Ian Roberts
In some instance, using StartTransaction and Commit improved performance,
except in one case, so I didn't use it in this case. I even contacted 4
vendors and ask them for ways to improve speeds. One of them never replied
but the others sent me suggestions.
The performance for DBISAM is pretty good. Only DISQLite3 was faster on all
respects. DBISAM was even faster than the Advantage Local server on all
except for indexing (this product is amazingly fast on indexing, faster than
any other product I have tested).
One also has to remember that those tasks were performed with a single user
access to the database and that the exclusive mode was enabled. So I doubt
they reflect the performance in a multi-user access.
Ian
"Tony Pomfrett" <to...@aline.com.au> wrote in message
news:45ab08bc$1...@newsgroups.borland.com...
Ron L.
>I updated the table adding DBISAM as well as a new task. Conclusion,
>DBISAM is indeed fast, as fast or faster than ADS on reading/writing data .
>It is however slower than ADS and DISQLite3 on indexing (but much faster
>than Absolute Database and Easy Table).
>
Just a note that there is a new product coming from the producers of DBIsam
called ElevateDB and the reports are that the areas of performance
enhancements include indexing and blob operation performance...
Ian Roberts
benchmark.
Will it be a single file database alternative? DBISAM has good performance,
but it is not a single file database, and for now, the best choice is either
Absolute Database, which quite slow on some tasks, or DISQLite3, that is
amazingly fast but has a syntax that, despite some recent efforts, is still
quite peculiar, different from the other BDE alternatives.
Ian
"Ron L." <info...@nospam-pireporting.com> wrote in message
news:45abbdec$1...@newsgroups.borland.com...
Ron L.
> If they send me a demo version of the beta program, I can put it to my
> small benchmark.
>
> Will it be a single file database alternative? DBISAM has good
> performance, but it is not a single file database, and for now, the best
> choice is either Absolute Database, which quite slow on some tasks, or
> DISQLite3, that is amazingly fast but has a syntax that, despite some
> recent efforts, is still quite peculiar, different from the other BDE
> alternatives.
My understanding is that it will not be a single file DB - but than, DBIsam
is not either...
I was just discussing the specific issue of index speeds of DBIsam vs. other
solutions because I have recently went through the process of selecting an
embedded database and had to choose between the 3 finalists of DISQLLite3,
Nexus and DBIsam. I did not have the requirement of a single file DB.
FWIW - I chose DBIsam as it seemed to offer the best combination of
stability, performance, ease of use and support for my needs - I do not have
EDB yet - but will probably get it as soon as it hits the market...
jeffc
Ralf, had mentioned to me that he felt his product was faster or equal to
DBISAM and it seems his comments are proven.
I understand that Ralf had mentioned that with his latest DISQLite version
you can you the normal TDataSet ways to access the tables and query them.
So why do you feel that it is still complicated to use?
Ian Roberts
> So why do you feel that it is still complicated to use?
Yes I still believe it is more complicated than the others. It us a little
bit easier now than before, but there is definitely a learning curve
involve, considering the fact that all other BDE atlertnatives could run
about the same source code (with minor modifications), but not DISQLite3.
For example, all other component could run the following code without any
modification:
for I := 1 to 100000 do begin
Table1.Append;
Table1.FieldByName('IdName').AsInteger := I;
Table1.FieldByName('Name').AsString := 'John ';
Table1.FieldByName('Random').AsFloat := Random * 1000;
Table1.Post;
end;
But not DISQLite3. Here is an example of a code Ralf sent me as a
replacement:.
DB.StartTransaction;
try
Stmt := DB.Prepare('INSERT INTO t VALUES (?, ?, ?);');
try
for i := 1 to 100000 do
begin
Stmt.bind_Int(1, i);
Stmt.bind_Str(2, 'John');
Stmt.bind_double(3, Random * 1000);
Stmt.Step;
Stmt.Reset;
end;
finally
Stmt.Free;
end;
finally
DB.Commit;
end;
You may be familiar the SQL syntax and find the above code quite clear, but
not all users will be as compfortable with this kind of codes and will
prefer something they are more familiar with. I changed database engines in
projects quite easily in the past, but rewriting an application to support
DISQLite3 would require a lot of rewriting. IMHO, Ralf should spend more
time trying to develop components that mimic the standard procedures and
functions used for database operations (such as
Table1.FieldByName('Name').asString). Of course, one could expect a speed
penality for those "higher level" routines, but if one has to optimize a
specific task in an application, one could still use the original DISQLite3
syntax.
Ian
"jeffc" <nos...@hotmail.com> wrote in message
news:45ae83a4$1...@newsgroups.borland.com...