Database for small company

[harry47]

I run a small publishing company and need a simple database which creates invoices, adjusts book inventory totals after sales and new additions etc.

The OpenOffice database seems to be quite comprehensive but I don't see the functions I need. Can it be used for such purposes or do I need something different?

[Villeroy]

You need a database developer.

[RoryOF]

My advice is to buy a readymade business database. In the past I used Quickbooks, which I found simple and straightforward. I believe (no personal experience) that Gnucash may be similar.

[harry47]

Thank you for your suggestions, but I am retired and do not feel that our limited sales are sufficient to motivate the purchase (or rental) of a commercial program. I'm looking more for an open-source or free business application, which can be used with Mac OS.

[RoryOF]

Developing a business database on OpenOffice will take much time. The few hundred dollars/euro Quickbooks will cost will be less than the ultimate cost of expenditure of time in developing a business database. Plus, you will also get access to user forums and perhaps support for a period. But it is your decision, of course.

I am not sure what commercial business databases are available for Macs.

[Villeroy]

http://gnucash.org/ is free

[harry47]

This was helpful – thanks.

[the_watchmann]

I have been using gnucash for 10 years now and I can vouch for it. I do the bookkeeping for a medium sized timber company and gnucash comes through rock solid. You can link it to sqlite3 for a really stable experience. I found the sqlite3 database to be less prone to losing data in the event of a system crash.

[joaofmateus]

I am incredulous!
In a forum on the Base, visitors are advised to use another product when their use should be encouraged.
And, as if that were not enough, they are still advised to look for a database developer when, I think, the BASE should essentially serve to be used by advanced users, or even beginners, who want to venture either in programming or in the construction of small (or large) databases.
In fact, this seems to come in the line of thought that has lately presided over the very development of the Base that, instead of making it more and more user friendly, has little or nothing to do with it!
I, who, I confess, already have some experience in database development, for databases with large tables and large amounts of information, I would never choose to develop them as the Base, but for simple and little databases volume of data would choose the Base, yes, if I were guaranteed the problem of data loss that, undoubtedly seems to me to be its most serious problem and which has not been given due attention by its developers, either for lack of means, or lack of knowledge!

[RoryOF]

One is not obliged to offer advice, but I believe that, if one does, it should be best advice. Knowing the learning curve and problems that might arise from an inexperienced user attempting a mission critical development (it is intended to be used in a business for invoicing etc) using Base and associated database, I advised that a commercial or an already developed product is best.

Are you prepared to hold the OP's hand and take him through the development of the application he proposes?

[Villeroy]

I am incredulous!

This is the same Base component since 2011. And between 2005 and 2011 there used to be 2 developers working on Base. They struggled hard to keep this compmonent up and running against regressions and they added small, nevertheless important, improvements to the functionality of 2005. Today we can be happy when someone from the Calc department takes a look at a serious Base problem.

The GUI tools which should allow you to click together some working database always have been insufficient because they have far too many gaps leading new users right into a huge mess of inadequate data types, all fields optional, arbitrary primary keys, no foreign keys and non-normalised tables constantly requiring new category columns. The tools do not even cover all features of HSQL 1.8, for instance it is impossible to apply any default value that is not a constant (DEFAULT CURRENT_DATE) and you can not have admin and user.

Are you prepared to hold the OP's hand and take him through the development of the application he proposes?

Users who barely can handle a spreadsheet with 2 data types don't cope with abstract design concepts and those freedom fighters with some Excel/VBA background immediately start to write macros in order to bypass any conceptual "limitations" (and of course they fail).
As a supporter you find yourself building up the whole database in question or compile a link list pointing to similar solutions. Writing the data definition SQL for a handful of tables, 10 queries, two or three forms can take a full Sunday afternoon. Demonstrating the underlying concepts by examples -- as close as possible to the user's actual problem -- is an efficient way to get "normal users" on track or lose them completely (which is also fine).