Binary incompatibility issue in JuK saved data
js at iidea.pl
Tue Jan 8 16:24:33 GMT 2008
Will Stephenson said the following, On 2008-01-08 11:33:
> Not to put down database storage, our database support is excellent, but for
> many uses it's using a hammer to crack a nut, and given the way people are
> taught computing these days, some will be tempted to go for what they know
Of course I like JuK very much; just let me correct a few misconceptions.
> and use a database where a simple binary format is good enough and performs
> better than loading a database library
not if we assume that the library is most likely already loaded into the memory...
> and a db file and initialising the database and doing a query.
The initialization of this hammer is as simple as calling open(2) and overhead
is equal to writing 30 bytes or so, all handled at a filesystem level==) Next
time you have to read the file, you don't have to load it entirely into the
memory in advance.
What I say is similar to opting for UTF-8 text files instead of keeping dozens
of CP/ISO encodings with all these various converters and autodetection routines.
Common storage format at certain level encourages data and schema sharing,
while custom formats require developing common-intermediate format or protocol
or API+data structures anyway.
regards / pozdrawiam, Jaroslaw Staniek
Sponsored by OpenOffice Polska (http://www.openoffice.com.pl/en) to work on
Kexi & KOffice (http://www.kexi.pl/en, http://www.koffice.org/kexi)
KDE Libraries for MS Windows (http://windows.kde.org)
More information about the kde-core-devel