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 lodg...@gmail.com On 4 March 2015 at 05:56, Heinrich Stöllinger <hc.stoellin...@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 <ville...@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+unsubscr...@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+unsubscr...@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+unsubscr...@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
