Date: prev next · Thread: first prev next last
2015 Archives by date, by thread · List index


Hi Heinrich,

I've been reluctant to join this discussion, but you comment about the need
to have "... a stable, scalable interface to REAL databases (with sometimes
millions of DB-tuples) ...", has prompted me to say that I believe one such
database already exists - it is called H2.  See -
http://www.h2database.com/html/main.html.

Some will perhaps reject it out of hand, because it is Java based.  However
it has a vibrant user base and from comments on the user group, some are
using H2 for very large databases.  A year or so ago one user was
complaining that H2 was slowing down after his application passed the 1
billion record mark!  In reply, he received several suggestions as to how
he might over come his problem.

I have migrated 6 databases from HSQL 1.8, (the largest having nearly
35,000 records - which I realise, is still quite small), but I have found
that H2 works well for me.  There was a bit of work involved with the
migration, but H2 tables can be designed in LibreOffice and the process
went  pretty smoothly.  Perhaps the only drawback is that once tables have
been designed, they can be altered only using SQL commands.  But I guess
most users who want an industrial strength database, would already be
literate in SQL.

My 2c worth,

Noel
--
Noel Lodge
lodgemn@gmail.com

On 4 March 2015 at 05:56, Heinrich Stöllinger <hc.stoellinger@aon.at> wrote:

Hello,
I am an "old" DB-User in the real sense of the word (I am over 70!).
In the 90ies I got into DB2 as a systems engineer at IBM. Then, around
the turn of the millenium, I set up a database for the administration of a
50-piece wind band, using Lotus-Approach (DBase...). It was fine
but I wanted to go "Open Software" and - when stumbling onto
StarOffice/OpenOffice and Base - it was clear to me to go for that
"scene". Since then I have been using MySQL as external back-end
and must say I am more than happy with it. My DB consists of some
80 interconnected tables/views with record numbers up to around
40.000. This is handled perfectly fine by MySQL (maybe MariaDB in the
near future!).
Of course - as an "old" DB-guy I have no qualms about using the
command-line mysql client directly for doing things like defining
DBs, tables, views, foreign keys etc. Therefore, if there are any
limitations
in the LO-front end, it is o.k. for me.
I do feel strongly though, that if we ever want LO to become a REALLY
important player (especially within the business world!), a stable,
scalable
interface to REAL databases (with sometimes millions of DB-tuples) will
have to be implemented. Internal, integrated backends are o.k. for
playing around but NOT for mission-critical, large-scale operations.
Regards
Heinz


Tom Davies schrieb:

 Hi :)
+1

One advantage of Base is that it can connect to such a wide range of other
database programs.  It is kinda the default way of using Base.  MS Access
can be twisted into using an external database but it's not as easy to
set-up that way as Base.

Kexi and other front-ends can be used either alongside Base or on other
systems by other users to use the same external back-end as the Base users
connect to.  Again this "playing well with others" is a huge advantage
that
Access doesn't have by default.


Sadly the marketing team, if and when they ever mention Base, focus on
using the internal back-end and never even mention the advantages that
Base
has.  This could be one reason why we see so many people using the
internal
back-end and comparing it negatively against Access.

Unfortunately the marketing team took such strong offence to my objections
to their attempts to market Base on it's weakest points instead of it's
strength that they banned me from posting to their mailing list at all.
Sometimes i am really not a "people person"!


I think if we do mention specific back-ends, especially if they are owned
by Oracle, then it is well worth pointing out other names.  It's not about
fanboyism, just about showing there are a wide range of choices - and that
people might well already have a database (or even spreadsheet) that can
be
used without any export-import conversions.  It is VERY good to know that
use of internal back-end can be externalised fairly easily without having
to go through all the troubles Ian Whitfield went through.  On the other
hand his move away from Java-based back-ends probably gave additional
benefits!


I definitely appreciate Andreas' posts in this thread!  He has cleared-up
several mysteries by explaining the problems "under the bonnet".  It has
also been good to see experienced and knowledgeable people giving
anecdotal
confirmation of Andreas' points.

In answer to Jay's question there was some attempt to move to using
"Firebird" rather than "HSqlDb" but i think that is still an "experimental
feature" and that we now effectively have a choice of 2 internal back-ends
neither of which work entirely as hoped for yet.  With Firebird it feels
like it is "on the way" though.
Regards from
Tom :)



On 2 March 2015 at 21:09, Andreas Säger <villeroy@t-online.de> wrote:

 Am 02.03.2015 um 21:23 schrieb Tom Davies:

Hi :)
Apparently another great database program to use as a back-end is
Postgresql.  Some of the Postgresql people worked with the LibreOffice
people to make a really good connector and then got that connector into
LibreOffice main trunk.

 This is not a matter of partisanship, fanboyism nor objective evidence
of the better product. The important thing is that you are able to
connect to whatever you already have. The database of your online shop,
your business software, your accounting software, some dBase directory,
spreadsheets or csv files. The connectivity feature lets you use tabular
data without troublesome export/import.

If all you have is an embedded HSQLDB, you can convert this to HSQL 2
within minutes. Conversion into Postrgre/MySQL/whatever would require
careful editing of SQL scripts, testing and possibly adjustment of
queries, forms, reports.



--
To unsubscribe e-mail to: users+unsubscribe@global.libreoffice.org
Problems?
http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/users/
All messages sent to this list will be publicly archived and cannot be
deleted



--
To unsubscribe e-mail to: users+unsubscribe@global.libreoffice.org
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-
unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/users/
All messages sent to this list will be publicly archived and cannot be
deleted


-- 
To unsubscribe e-mail to: users+unsubscribe@global.libreoffice.org
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/users/
All messages sent to this list will be publicly archived and cannot be deleted

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.