C database :: compared to a relational database engine?

[user923005]

It just seems to me that w/ the current uC computational power,
performance return from a relational database engine is not really
much better than C.

Sure, the database companies have spent billions making queries as
fast as possible, but you can do better with C by yourself.

Or is it that a SQL query is faster to code than
to hard code the C program?

Which would you say is easier:
1. Type in a SQL query
2. Write/test/debug/document a C program that performs the same
equivalent query

As to remote access, that does not really
pose a problem w. POSIX. Or, were you thinking about concurrent use of
a file? i.e. is contention easier to manage w. a RDB engine compared
to root file systems? And I guess that poses another perspective; C
programs must have a root filesystem (and less portability) whereas
a .db file can be easily ported to another OS?

A database will give ACID properties to your transactions.
A database will give security to your transactions.
Do you value your data?

A database will have been tuned for performance.
Do you value your customer's time?

A database can execute any query that follows the definition of the
query language.
Do you value your time?

If permanent storage of data is needed then a database springs to mind
as a simple, fast, safe and often free choice.
Rolling your own solution will be very difficult if it is to compete
on a capability and/or performance basis.

IMO-YMMV.

 

[Chris Thomasson]

Hi,
I am working on a program to archive data to disk.

At what point is it best to use a relational database like MySQL as
the backend instead of a C program alone?

Just remember that you can code a relational database in C. However, that is
not very practical at all... So, if you don't feel comfortable wrt creating
your own solution, well, you can always license somebody else's hard work.

 

[sonos]

sonos skrev:
I am working on a program to archive data to disk.
At what point is it best to use a relational database like MySQL as
the backend instead of a C program alone?

[...]
It just seems to me that w/ the current uC computational power,
performance return from a relational database engine is not really
much better than C.

I didn't realize from your initial posting that you were working on
embedded systems. That adds two additional criteria:

* Is there a client library available for your target system at all?
Even if your system is POSIX-compatible it may have restrictions which
the authors (which were developing for servers and workstations)
simply didn't think of.

* Does it fit on your system? The MySQL and PostgreSQL client libraries
seem to be rather small (a few 100 kB), but for some RDBMSs the client
libs (plus support files: charset conversion tables, error message
catalogs, etc.) are huge (tens of MB).

hp

MySQL is available in embedded form (~1MB), but the customer is
wanting to avoid vendor lock in. MySQL AB is leaning in that direction
by locking src to paying customers only. Amazon's S3 service basically
puts the entire database in cache, so advancing hardware technology
appears to be making inroads on the RDB software performance. Clusters
are an option I suppose, and C would be the primary language anyway.

I suppose it's a matter of develpment budget and time to market. With
C, I am presuming a well coded embedded<>server data system will
continue to be a viable solution for the years ahead, and one I'll
place my dollar on. Might I be so bold as to say within 10 years RDB
will not always be the 'knee-jerk' solution to data management apps.
And, if quantum computing ever arrives, well, hardware solutions win
hands down.

Anyway, thanks for your insights on the matter. I know much has been
OT, but asking the RDB usenet groups wasn't the perspective I was
looking for either.

 

[sonos]

A database will give ACID properties to your transactions.
A database will give security to your transactions.
Do you value your data?

Will you elaborate?

 

[user923005]

Will you elaborate?

ACID:
http://en.wikipedia.org/wiki/ACID

What happens to your data if the power fails or someone kicks the plug
out of the wall in the middle of a transaction?
If you use a database, then nothing bad will happen. If you use a
disk file, then lots of bad things can happen.

Security:
http://ieeexplore.ieee.org/Xplore/login.jsp?url=/iel5/8858/30659/01416861.pdf?arnumber=1416861

There are bad people who would like to peer into your data and get
unauthorized access to it or damage it.
Database systems provide access and audit mechanisms to prevent that.

If your data is disposable, then any sort of dictionary structure is
probably good enough. If your data needs to be durable, then a
database is one obvious solution that solves lots of problems.

 

[Tor Rustad]

user923005 wrote:

MySQL and PostgreSQL have huge footprints and require a server
installation.

Perhaps SQLite or FastDB would be more appropriate for embedded work.
http://www.sqlite.org/
http://www.fastdb.org/fastdb.html

Berkeley DB is another option, and doesn't require a DB server.