[Lazarus] Embedded database for Lazarus/Linux

[waldo kitty]

On 6/18/2010 03:36, Hans-Peter Diettrich wrote:
> waldo kitty schrieb:
>
>> i'm (still) trying to figure out why one would have an embedded
>> database with multiple embedded apps attempting to talk to it...
>> concurrently or otherwise... i would think that any kind of concurrent
>> multiple access needs would be better served by a (dedicated?)
>> database server...
>
> ACK. It's easy to have multiple apps accessing the same data base (of
> whatever kind), e.g. multiple Lazarus IDE instances...

yup! even if the database is a binary design of one's own work ;)

>> i still find it amazing, though, that in today's world, so many opt to
>> use a sql database of some kind even for smallish projects where a
>> nice simple self-designed binary data file would suffice... in many
>> cases, it is akin to swatting a fly with a hydrogen bomb ;)
>
> What are the alternatives? If you already had to update a binary file
> format, for required extensions, you'll know about the problems with the
> conversion from the old to the new format, and with the synchronization
> of the load and store procedures. A database should do all that
> automatically, whenever the common model is updated.

this is true and i don't dispute it... one of the points is that using a 
database server and such removes that level of detail from you, the coder, and 
you no longer have to worry about it... on the one hand i can understand and 
agree with this... on the other hand, though, i see where new folk coming up are 
not getting the full experience and teachings that they should have... 
especially if binary data files is only one day in their programming course and 
they move to using a database and spend much more time on it... i feel that this 
gives a false sense and idea that using one's own binary files and working out 
one's own access routines is a BadThing<tm> when it is not...

> XML files are no real alternative, they typically lack a "TOC" with all
> available or mandatory entries, that have to be specified and respected
> in application code. Of course there exist *means* to describe the XML
> content structure, but that feature is based on very complex descriptions.

yeah... i've looked at XML but haven't truly seen a need for it... i understand 
what folk are explaining about it but i've just not seen a real need for it...

> The Windows Registry is another (poor) attempt to provide structured
> data storage, with only structured acces methods, but no description of
> the structure itself.

you found that, too, eh? :)

> That's why "traditional" (relational) databases, with a number of named
> tables and entries, IMO offer both a simple structure definition, while
> leaving much room for common or special (SQL) statements for data
> retrieval and storage.

as in the case of XML, it has taken me some time to get wrapped around SQL... i 
can understand why it was created but its goal wasn't fully achieved and just 
like before SQL came along, there are still several differences between them... 
so nothing has truly changed...

> In so far a XML solution will more resemble the hydrogen bomb, compared
> to a simple DB solution. A database system is not necessarily a big
> piece of code, as shown by the embedded solutions, and the SQL query
> features can be applied as another layer on top of any concrete DB model.

this is true... it just seems that many things are over-engineered for various 
reasons... one being as i depict above which can easily be expanded to cover 
more than just the binary data file example given... there are other reasons, 
too but these are what i have seen and been able to actually "touch" as to being 
/the/ "problem" (at it were)...