I remain concerned about TDF's abandoning it, with the result that it slowly falls apart with each release,
For all practical purposes, the database component of OOo was treated
like the red haired stepchild. Under the TDF, LibO has simply continued
that mistreatment.
I'm planning to try using it as interface to an sqlite backend very soon, as that engine will surely meet my needs.
When the discussion about which _additional_ database engine OOo should
include. HSQLDB won, and SQLite lost. From my POV,the only reason HSQLDB
won, was because it used Java. At the time, it was technically inferior
to SQLite.
In an ideal world, there would be an extension that installs SQLite as
if it were built into LibO, and provide a usable UI for database
creation, editing, and viewing.
but the real issue for me isn't the db engine but the interface.
This relates to who creates databases.
There is a lot of useful theory, and practice in database construction
and maintenance. For most projects, applying that theory would be
helpful. Which is why database designers are very reluctant to allow
non-database designers to create databases. Or, more bluntly, don't
like pre-built tools that non-database designers can use, to create, and
use databases.
The simple reality is that when there is not an obvious, easy way to
construct a database, people will use spreadsheets, blithely ignoring
the fact that spreadsheets can, and will destroy their data. Then, since
most people use spreadsheets instead of databases, development of
database tools for Joe Sixpack gets lowered in priority, eventually
reaching the point that databases for mortals are considered irrelevant.
I need to be able to design and run forms. If I don't use Base to do
this, what else is there in the opensource world?
PERL, Python, Ruby, etc.
I'm a bit baffled by the database engines that present themselves to the
world bare. Apparently one just writes one's own interface for them,
Historically, database engines have shipped without an interface. The
user was expected to write their own UI. This presents the fewest
restrictions on the database designer.
By way of example:
I create resources for various Bible study programs. These all use
databases for the content. With a generic UI, I can't force record 31102
to be Revelation 22:21, or validate Vulgate versification as it is
entered. With a custom UI, Vulgate versification can be input, and the
data automatically converted to KJVA versification.
For the non- IT-professional this is essentially a non-starter.
Database designers are the last hold out in the IT World, thinking that
they are gods, and nobody else is pure enough to do what they do.
All that said, I do think that a manual that focuses on using the Base
component as a front end to PosgreSQL, MySQL, Mariadb, Drizzle, MS
Access, etc. A second manual, focusing exclusively on SQLite might be
justified.
jonathon