Re: alternatives to Firebird: sqlite

On 8/03/2016 15:47, Dan Lewis wrote:
> On 03/08/2016 06:47 AM, SOS wrote:
> > A disruptive solution could be to abandon the "embedded"  idea and 
> > replace the current embedded engine by a new engine who use a 
> > spreadsheet file  as a "editable" storage who is protected for 
> > accidental editing.
> > Currently the use off a spreadsheet as database works fine en is fast 
> > enough for most small data sets. Just makes this system, editable.
> > For bigger data sets, users can and will use a database off there own 
> > choice yo  been connected to LO.
> > Greetz
> > Fernand
>      Abandoning the "embedded" idea may be a good idea. One of the 
> things that Base does is connect to a spreedsheet, but how does one 
> use Base in this manner to create a relational database? Just how 
> involved with such a speadsheet be? What would the RDBMS be for a 
> relatational database? (DBMS is not designed for a relational database 
> as I understand it.
That's what I mean with "new engine" who must be capable to make the 
relations-joins with SQL statements  between the different sheets in the 
spreadsheet.
>      Dan
> > On 8/03/2016 9:02, Lionel Elie Mamane wrote:
> > > On Tue, Mar 08, 2016 at 09:59:18AM +1100, Chris Sherlock wrote:
> > >
> > > > Oh, and I’m not sure if this brings much to the table, but I wonder
> > > > if we can simulate joins. After all, to get a right join you just
> > > > swap tables, and you can actually simulate a full outer join with
> > > > just a combination of other joins.
> > > See the last part of
> > > https://lists.freedesktop.org/archives/libreoffice/2016-March/073572.html 
> > >
> > > "compatibility with other databases" was a reference to
> > > https://bugs.documentfoundation.org/42165
> > > https://cgit.freedesktop.org/libreoffice/core/commit/?id=c25bb400bbfe20b3b13237ed10935ec9d0f6d769 
> > >
> > >
> > > In short: yes, it can be done.
> > >
> > > All these issues add up, and in the end I summarise them as "It is
> > > probably possible to build a 'compliant' database on top of SQLite,
> > > but SQLite is not that by itself". That is, we can "use" SQLite as a
> > > (big) chunk of our embedded database engine, which we would DEVELOP
> > > OURSELVES, but it is not "take a database engine and embed it in
> > > LibreOffice". It is "develop our own database engine, using SQLite as
> > > a foundation that gets us many many percent of the way, but not the
> > > full way". If someone wants to do that, and commits to maintaining it,
> > > then fine. Glad to take patches / see it integrated. *If* it comes
> > > with a serious intent of maintaining it! Note that the ODBC driver
> > > basically does that. So yeah, doable. Can be redone. Maybe we could
> > > even embed the ODBC driver in some way. I have some uncertainties
> > > around this, because I think that ODBC drivers "need" a driver manager
> > > (that's what the Microsoft documentations say somewhere), but I never
> > > really understood completely why, and some FLOSS ODBC drivers *are*
> > > meant (by their author) to be able to be used without driver manager,
> > > I think.
> > >
> > > See also
> > > https://bugs.documentfoundation.org/show_bug.cgi?id=38811#c21
> > >
> > >
> > > What SQLite does it not necessarily bad, it is *different*. Dynamic
> > > typing has its uses and its advantages. Just as NoSQL. But it makes
> > > them a "bad fit" for a framework centred around the "classic" / usual
> > > strong-type SQL.
> >
> > _______________________________________________
> > LibreOffice mailing list
> > LibreOffice@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/libreoffice
>
> _______________________________________________
> LibreOffice mailing list
> LibreOffice@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/libreoffice