Small Business Database

[JP @ TSS]

Hi, new guy here. A friend and I recently started a (very) small business and i want to use OpenOffice to help run it.

I'm looking for a pre-built database (inventory, accounting, customers, vendors, etc) so I won't have to start from scratch. I have built databases before, but just looking for a time saver that I can tweak. The options I have found online are templates for specific documents or tables and I'm looking for a small business application.

If anyone can point me in the right direction, I would appreciate it.

Thanks.

[John_Ha]

Welcome to the forum.

You are setting up a business to do what you know well and can do better than other people. You don't know databases - learning to make your own will eat into your time, money and patience and even then, it will not work as well as a professional one. Buy one from the professionals who know how to do it and who have done it hundreds of times before.

Ask Ms Google what she knows about small business database solutions - she has 26,000,000 suggestions.

Search for organisations which help small businesses in your country - in the UK there are many including smallbusiness.co.uk which has Six signs that it’s time to change your ERP software. Can you handle any of the six?

If you want to progress with Base - trust me, you don't - then check the Business and Paid Support forums on this page.

Base is not the easiest of applications to use. Search the forum with business for ideas (https://forum.openoffice.org/en/forum/s ... mit=Search) - it threw up Using AOO Base for Small Business Sales and I agree 100% with what it says.

See Database Examples and the other forums here.

Search the libreoffice.org site for documentation - the LO Base Handbook is better than the AOO Base manual at AOO documentation.

[John_Ha]

Also see [Solved] Sum values on main form and in subform grid column which includes:

The file appears to reflect faulty database design in that few proper relationships are established between the source data tables in the database.

An invoice database can be quite complicated. Typically, at the very least, it should reflect the one to many relationship between Suppliers and Invoices, similarly between an Invoice and the Lines it contains, and similarly between a purchase Item and invoice Lines. These are each quite distinct entities and will require individual, but referenced, tables if the database is to ensure integrity and avoid unnecessary redundancy.

An initial introduction to database design relevant to Base can be downloaded from https://wiki.documentfoundation.org/ima ... torial.pdf. It is significant that many pages in that tutorial are devoted to design principles before addressing forms or queries.

Then again Base may not be a wholly suitable route if the intention is that the database is to be used for serious commercial purposes. The default database application embedded in Base is suitable for little more than learning and demonstration purposes: commercial reliability will inevitably require upgrading so that Base works with a split or separate database engine. It should also be recognised that starting an initial RDMS project by designing a commercial database is unlikely to be economically justifiable: an off-the-shelf purchase or hiring a professional may well be a cost that proves financially more rewarding. On the other hand it can indeed prove to be a challenging and enjoyable education exercise.

and

I have seen several enterprises fail when an unreliable Purchase Ledger caused loss of cash control.

Any relational database that ignores the key principles of normalization sooner or later produces unreliable results. I fear all the care and effort already devoted to "Open PLA 5.3.2.2.g.odb" will be abortive if it is not grounded on a sound relational database design. Starting at the deep end is risky and better avoided. I suggest it will be difficult, if not impossible, to achieve your aim, as quoted above, without first gaining an initial understanding of the theoretical principles that underlie a relational database. An understanding of these principles is more readily proved and tested on the design of token or simple databases before embarking on the critical complexity of one that is intended for commercial accounting.

and, in a comment about the suggested database

It [the user designed database] demonstrates how it shouldn't be done.

[RoryOF]

If I were using Windows I'd try Quickbooks. My experience with it some 15 years ago was very positive.