The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Advangage/Disadvantage about embedded database engines

Hello, Everyone.

I want to implement software which needs a embedded database engine. I search this forum so many times. The language I must use C++. Then I have two methods to choice:

1.    VisualStudio C++,  OLE-DB,  SQL Compact 3.5
2.    VisualStudio C++,  IBPP, FireBird

Is anyone has the same choice? I want to know both the advantage and disadvantage of them.
Waiting for your opinion. Thanks!
Vincent Suo Send private email
Friday, April 18, 2008
 
 
I would choose 2)
for speed we use ibpp for flamerobin and is one of the fastest
database applications i have ever seen: i always stare at how fast it is compared to let's say an ajax application(gmail) or java one (eclipse)

also there is an ole-db driver for firebird too
http://www.google.com/search?q=OLE-DB+firebird
Popa Marius Adrian Send private email
Friday, April 18, 2008
 
 
you should look into SQLite. It's written in C but has many C++ wrappers and source code is in public domain.

Many applications use it, it's very stable, reliable and clean peace of work. Google uses it in some of their products like Google Gears for persistent storage.
lubos
Friday, April 18, 2008
 
 
you can read another thread with firebird on joelonsoftware on how firebird is better vs sql ce

http://discuss.joelonsoftware.com/default.asp?design.4.607273.34

By the way a new version for firebird2.1 was just released with
64 bit versions for all platforms (windows,macosx,linux)

http://www.firebirdsql.org/index.php?op=devel&sub=engine&id=fb210_release
Popa Marius Adrian Send private email
Friday, April 18, 2008
 
 
For Popa:
Thanks for your information! I will consider the firebird.
 
For lubos:
I hear that the SQLite cann't encrypt the database. Is that right? I need to take a high security level. Thanks!

^_^

Friday, April 18, 2008
 
 
What about multi-threaded applications? Can sqlite or firebird handle being accessed from multiple threads?
db
Friday, April 18, 2008
 
 
sqlite is fine being access by multiple threads/applications.
it does not have native encryption, but you could certainly encrypt anything you like when storing the data.

-don
Don Dickinson Send private email
Friday, April 18, 2008
 
 
As usual, it depends on what you are trying to do.  We are using Firebird embedded and it works very well for us. 

As the SQLite documentation says: "Another way to look at SQLite is this: SQLite is not designed to replace Oracle. It is designed to replace fopen()."  Since we essentially WERE trying to replace Oracle, we rejected it.  Some specific limitations we noted: 

 - No native temporal data types (you have to use strings and functions)
- No built in collations
- Limited join support
- No type enforcement

So if it works for you, it is nice and small and has a lot of positive buzz.  But if you want a real database for embedded data analysis, Firebird is a much better choice.
Richard Wesley Send private email
Friday, April 18, 2008
 
 
If you want a light weight, easy to use, well supported and fast Embedded SQL DB SQLite is the way to go.

Firebird is a more complex, bigger beast with scrappy documentation and strange limits like max 32K columns, Blobs stored outside the table.
Neville Franks Send private email
Friday, April 18, 2008
 
 
OMG! "BLOBS OUTSIDE THE TABLE"!! WE'RE ALL DOOMED!!!

Ok, kid. Go to home and do your homework.

Who the hell would (try to) compare two things so different like SQLite and Firebird/PostgreSQL/Oracle?

BTW: Blobs were CREATED by Firebird/Interbase. And about limits: give a look in Firebird v2.0.
F.D.Castel Send private email
Saturday, April 19, 2008
 
 
>BTW: Blobs were CREATED by Firebird/Interbase. And about limits: give a look in Firebird v2.0.

I looked at the Firebird 2.0 release notes before posting and couldn't see anything about changes to limits. I also tried to find a reference to what the limits are and after 10 minutes of searching I gave up.

Can you give me a reference URL please?
Neville Franks Send private email
Saturday, April 19, 2008
 
 
Here's a comprehensive comparison of many RDBMSes:
http://en.wikipedia.org/wiki/Comparison_of_relational_database_management_systems

My current favourite is Firebird, but ScimoreDB is looking very interesting.
Mark Pearce Send private email
Saturday, April 19, 2008
 
 
Thanks Mark. I'd not heard of ScimoreDB before and it does sound very interesting. Note though that it requires Microsoft .Net 1.1 and has 3M footprint, neither of which maye be issues for some. Further it is not Open Source, nor is the source available it seems.
Neville Franks Send private email
Saturday, April 19, 2008
 
 
>> Further it is not Open Source, nor is the source available it seems. <<

I would rather suffer death by nipple-elongation than look at the source code for a RDBMS :-)
Mark Pearce Send private email
Saturday, April 19, 2008
 
 
Unless you have a decent reason not to, bite the bullet and just use Jet.

I swear, some people just want to complicate life.
Shebeezers
Saturday, April 19, 2008
 
 
"strange limits like max 32K columns"

If you need more than 32,000 columns, you're doing it wrong.
Iago
Sunday, April 20, 2008
 
 
I was nearly decided to use Firebird Embedded in my .NET Winforms application. I tried to test everything and FB performed very well. Everything was OK until I tried to open a database located in a path containing special local characters like ěščř etc. Unfortunatelly, the .NET provider is not able to talk to the FB core in a "national dialect", and this is a show stopper for every application being used worldwide. If you want to store your database in a user's profile on non-English Windows, FB will not work and there is no workarround. There is one trick with DOS 8.3 names, but this doesn't work on FAT32 AFAIK.

Now I switched to SQLite and so far it looks good. The only thing I miss is Unicode collations (there are other limitations as well, but I don't need complex database anyway).
Petr Veit
Sunday, April 20, 2008
 
 
+SQLite if the few limitations don't affect you.

Encryption support is available for a fee from the database maintainer D. Richard Hipp.  One time fee of $2000
http://www.hwaci.com/sw/sqlite/prosupport.html

And although it doesn't enforce types, it does use a few native types internally -- not everything is stored as strings.
Doug
Sunday, April 20, 2008
 
 
>"strange limits like max 32K columns"

>If you need more than 32,000 columns, you're doing it wrong.

No, I meant a column is limited to 32K of data. At least last time I looked. It is hard to find if this has changed.
Neville Franks Send private email
Sunday, April 20, 2008
 
 
Neville,

I found table with firebird limits in less than 3 minutes on the web. The path was obvious for me:

http://firebirdsql.org/ -> Documentation -> Firebird documentation index -> Firebird database limits
Oleg Deribas
Sunday, April 20, 2008
 
 
> I hear that the SQLite cann't encrypt the database.

As far as I know, Firebird doesn't support encryption of the database file either - although I guess this depends on what you mean by encryption. Take a look at http://www.firebirdsql.org/manual/fbmetasecur-solution.html for more information.
Gareth Send private email
Monday, April 21, 2008
 
 
>Neville,
>I found table with firebird limits in less than 3 minutes on the web. The path was obvious for me:

Thanks Oleg. Now I recall the showstopper for me was Maximimn Row size of 64K. I don't understand why there are such limits in the year 2008.
Neville Franks Send private email
Monday, April 21, 2008
 
 
Neville,

Personally, I see no problem in this limit, provided that you could always use BLOBs for storing virtually unlimited data volumes in every row.
Oleg Deribas
Monday, April 21, 2008
 
 
>Personally, I see no problem in this limit, provided that you could always use BLOBs for storing virtually unlimited data volumes in every row.

Oleg, I'm interested in storing documents that can exceed 64K and want to be able to use things like full text search. If I'm not mistaken you can't use full text search on blob's. And it is text, not binary data, so why should I be forced to use blob's.
Neville Franks Send private email
Monday, April 21, 2008
 
 
> Now I recall the showstopper for me was Maximimn Row size
> of 64K.

This is a ridiculous limitation. The limit should be your harddisk size!
cynic
Monday, April 21, 2008
 
 
Actually, without the maximum row size data efficient indexing, inserts, and selects become impossible.

You could make the limit bigger, but I'd leave that up to the DB optimizer guys. Databases are intended to store structured data, after all, not documents.
Chris Tavares Send private email
Monday, April 21, 2008
 
 
>Actually, without the maximum row size data efficient indexing, inserts, and selects become impossible.

Chris, FYI the default maximum row size in SQLite is 1,000,000,000 bytes (1B). It can be increased to 2^31-1 or 2147483647 with a recompile.
Neville Franks Send private email
Monday, April 21, 2008
 
 
Thanks for all of you!
I learned so many things from here. ^_^

For Petr Veit:
>Firebird Everything was OK until I tried to open a database located in a path containing special local characters like ěščř etc.

Is there any solution for this? It's a very bad news for me. @_@!
Vincent Suo Send private email
Thursday, April 24, 2008
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz