Hi

I plan to program an application which needs to store rather complex data. At first I wanted to build my own file format, but that turned out to be harder than anticipated. So now, I'm looking for a database system that is suitable for my application.

First of all, it's important to mention that I've had a lot of experience working with MySQL (in connection with PHP), so it would be kind of logical to keep using that system. Or maybe something similar (PostgreSQL?). But then, PHP is a lot different than C++, at least in my opinion. For example, is there a way to profit from C++'s object-orientation? And I can't expect all the people who want to use my application to install a MySQL server...

Basically, what I'm looking for is not a database server, but a database library. One that writes directly to the file system without contacting any server application, and that allows me to handle the data in a more object-oriented way.

Of course it would be a nice feature if the user could manage his data over a network, but it's not really necessary. And there is absolutely no need to share the data with other people, the application requires that only one person use the database, otherwise the whole thing wouldn't make any sense. So using a server wouldn't be of any use here...

TIA,
DeNayGo

Hmm.

You could, if you wanted to roll your own, use the B-tree library functions (and they can be painful) or you could build a C-ISAM-style (index file with offsets into a binary data file) application. The problem with either of those is that you more or less have to invent what MySQL (or Oracle or PostgreSQL or whatever) already do for you; i.e., the search capability.

The truly nice thing about MySQL is that it is a full-function RDBMS and pretty much all you have to do is figure out a good schema and indexing strategy and you're good to go whether you chose to have a PHP-HTML interface, command line interface, or stand alone program interface to your data. Another nice feature is that MySQL is, well, free. An additional feature is that the thing is fast, efficient and rock solid. Expecting (or requiring) a MySQL DBMS server on a target system is not a great burden on too many people (well, maybe the Windows folks, but even that isn't too much of a load to bear).

If you follow ANSI/ISO standards for your schema, you can ship your application to pretty much anybody and they can, with minimum trouble, build it on their own DBMS -- that means "strict standards;" no including extensions and the like -- most DBMS' I know of will happily accept ANSI/ISO schemas without choking too much.

It might be a good idea to not reinvent the wheel if you don't have to -- use the engine, take advantage of its performance and other capabilities, and custom build whatever you require on top of that rather than, essentially, starting over from scratch. You already know MySQL, you already know PHP (and probably HTML) for the GUI crowd, why not take advantage of that -- I kind of doubt that you'll get much in the way of performance or efficiency improvement with C++ (although you could if your data lend themselves to a B-tree or C-ISAM-style data base), but doing custom programs with C++ against a MySQL (or whatever) DBMS might be a way to go; try it and see.

Best of luck.

Postgres accommodates many aspects of Object-orientation very well.

If a full-fledged server isn't what you want, maybe have a look at sqlite ...

http://www.sqlite.org/



Cheers,
Tink

Hi -

You might want to search around for "Embedded Databases".

If you were on Windows, the embedded version of SQL Server (MSDE) would be a very likely choice.

For Open Systems, check out Berkeley DB, from Sleepycat Software:
http://www.sleepycat.com

And I believe there's even an embedded version of MySQL (although I'm not at all familiar with it).

Here's another link that might be helpful:
http://www.theserverside.com/news/th...hread_id=32338

'Hope that helps .. PSM

PS:
I was typing this at the same time as Tinkster. I forgot about sqlite: another excellent candidate!

Thanks a lot for your suggestions.

It would be a lot easier to use PHP, and I was already working on a web-based version of my program when I decided I wanted to share it with other people. Well, aside from using C++, I had two options: put the application on some server and let other people use it, or give them the program and let them care about MySQL, Apache and PHP... I didn't like the second one, cause it's... unusual, at least for a normal application, and I didn't really have a server, so I chose to create a nice KDE application.
I do believe that C++ makes an application both faster and better. PHP is a script language, i.e. it's 'compiled' (okay, it is not compiled, but interpreted, or however it's called) while it is used. That slows the whole thing down a little. In addition, a real application can interact with the system, in whatever way necessary (e.g., I plan on putting it in the KDE system tray).

By the way, I built my own database system during the summer, with search and sorting and everything, and then I threw it away, because of one little mistake (I could still use it, but somehow I don't want to, cause I know it's buggy like hell). Anyway, that showed me it's a lot of work, doing such a thing, and then, after so many hours of work you suddenly realize that apps like MySQL have probably taken a lot more than a couple of weeks of programming^^.. so I completely gave up building my own DBMS.

Right now, the worst solution would be using PostgreSQL (I feel like trying out something new) in connection with a typical KDE application, but I'll only resort to that in case I don't find a good "embedded database".

Is there a C++ library to communicate with a PostgreSQL server? One that enables one to handle rows in the database like objects in the program?

On the website, it says it's a C library. I mean, I could live with that, even C has objects of some kind (structures), if I remember correctly... but somehow I'd prefer C++. It looks nice though, I think I'm gonna read some of the information on that website..

My program is gonna be partially open source. Ok, let's just say completely.. the other part may need a database, but no one needs the other part... so I guess I could use that one. Does it use C++?

That sounds interesting... btw, is MySQL open source, GPL, etc.? I only know that it's free...

They're described as being "pure-Java", does that mean you can't use them with C++? If so, I won't be able to use them, since I haven't learned Java, yet (I plan to start very soon, though).

DeNayGo

There sure is... there's libpqxx
http://www.postgresql.org/ftp/projec...ibpqxx/stable/
And if you're using KDE, why not just exploit Qt's built-in SQL
classes? They handle Postgres very gracefully.

I don't think it supports OO concepts at all - you'd have to take
care of that.


Cheers,
Tink

So.. I've done some research and stumbled across ODBC. Is it true that I can use MySQL, PostgreSQL, SQLite and many more databases simultaneously with that?
The only problem is that I have no idea how to get the Qt ODBC plugin (it's not where the documentation says it is), and the only other ODBC library for C++ I know (libodbc++) seems to be in its very early development. But that's not really what I want to ask here.

Do you know if there are many distributions that ship ODBC? Can I expect an ordinary user to be able to build the Qt ODBC plugin?

Moin, und "Alles Gute zum Geburtstag!" :}

Well, you'll have to do some set-up per connection, but basically: yes
Just bare in mind that the native drivers will always deliver better performance,
and that Qt supports heaps :}

What distro are you using? Try
locate -i odbc|grep -i qt

I wouldn't expect the ordinary user to be able to build anything. ;}



Cheers,
Tink

Uh ... wait a second!

ODBC is a API library that lets you talk to a database.

ODBC APIs are *portable*, so you can talk to many different kinds of databases (mySQL, DB2, Oracle, MS-SQL Server, etc etc) without (substantially) modifying your program's code.

But you still need a database to talk to. As well as DB-specific runtime support in order to communicate with it. ODBC is only part of the story - it isn't the whole solution.

You were originally looking for an "embedded database". Is that still the case?

Danke!

Yeah, I'd have to restrict myself to the features that all databases support, and I'd really prefer using just one specific DBMS. The problem is that I don't want to tell the users they have to install PostgreSQL, although they already have MySQL, or maybe the other way around. Seeing as I can't seem to figure out what ODBC really is, that might happen anyway.
Heaps? Used for sorting and the like, right? That would replace some of the things the database does, but I'd still need to save the data somewhere. And somehow, I think I like SQL..

Gentoo; I've already tried searching for any files that contain "odbc" and haven't found anything. If I had installed Qt with ODBC USE-flag (some Gentoo thing, not important), I'd probably have it somewhere, but one year ago I didn't know what that is. And know I don't have the source of my Qt-version anymore, and it seems it's been deleted from the servers, too. I could update Qt, but then I'd either have two Qt-versions on my computer (or doesn't that make problems), or I'd have to update KDE and all its applications as well, since they all depend on it.

Ok, let me rephrase the question: Can I expect the ordinary Linux user to somehow get that plugin (which I can't seem to do)?

I know.. some of that. My understanding was this: my program talks to a library (e.g. libodbc++), that library talks to some type of ODBC core application, which then takes the appropriate ODBC driver, and then that ODBC driver talks to the database.

I guess "DB-specifig runtime support" means that the SQL queries I execute have to be understood by the DBMS? But that shouldn't be too much of a problem, I think there's always a way to "say" it so that all DBMSs understand it, isn't there?

But basically, it's not much different than using several SQL libraries (libpqxx, SQLLite, MySQL library, if there is such a thing) and handling them through some simple self-made SQL driver? If so, I might do that instead.

I'm not so sure. I could just decide to take Berkeley and the problem'd be solved. And I may still do that. But I realized that using a database server would make the program portable (it would enable me to build a second version of the program, for instance with PHP, that could be used on other systems).

DeNayGo