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


On 02/06/2012 02:45 PM, Dan Lewis wrote:
On Mon, 2012-02-06 at 19:51 +0100, Andreas Säger wrote:
Am 06.02.2012 19:22, Dan Lewis wrote:
         I wonder how many people who use LO have read chapter 8 of the
Getting Started Gude, "Getting Started with Base"? I know that I have
very seldom seen a comment about its contents. (I wrote it and am
presently updating it. I'm also working on the Base Guide in its
entirety.)

Dan
Sorry, that guide is too light weight. The matter is as abstract as a
programming language. It takes an IT guy with some theoretical concepts
and experience. Most parts of the helping Base tools are useless. They
can not do what they pretend to be made for. Most importantly, the form
wizard can not build forms. Most of the possible types of forms have to
be drawn by hand and you need to know very well what you are going to do
when you build up your own hierarchy in the form navigator.

A little bit of click experience with MS Access is not enough to design
a relational database connected to Base just like some experience with
the VBA macro recorder and code completion does not qualify anybody to
program anything outside that specific context.

The problem is that too many new developers try to learn having their
hands on the problems they are trying to solve right now. This is very
inefficient.
In my opinion, the "mid level tutorial" by Mariano Casanova is the best
guide to start learning about databases in general in the context of the
Base component:
http://openoffice.org/projects/documentation/downloads/directory/Base/Mid%20level%20Base%20tutorial.
Most importantly, the term "macro" occurs only twice on 189 pages.
      And it appears that you just explained why people will use
spreadsheets (incorrectly perhaps) instead of a database. You just
raised the bar too high for the average person. Why would anyone want to
learn something as abstract as a programming language before creating a
"simple" database?
      And the "mid-level tutorial" you mentioned contains this quote at
the beginning: "Step-by-step guide to producing fairly sophisticated
database applications with OpenOffice.org Base, from initial problem to
final product complete with
forms and reports."
      You obviously have a very in dept knowledges of database and can do
many things with them that others can not do. But that does not mean
others have to have a detailed knowledge of databases before they can
create them. Not everyone has a need for a "fairly sophisticated
database" to meet their needs.
      Yes, there are databases that need the DBMS to rely upon as much of
the SQL language as possible. (The latest Oracle program with its PL/SQL
might be what they need.) For help, you would be a good person to ask
advice from. And there are many databases that will run using Base with
its "infamous" 1.8 database engine. For some of these, the Getting
Started with Base is all the person needs. For others, the future Base
Guide will be sufficient.
      I think this thread came from a another thread in which a
spreadsheet was used as a database and the question involved changing
the names of the sheets of the spreadsheet. If a database were
constructed to do what this spreadsheet does, that would be time
consuming and require someone like yourself with a great deal of
knowledge of database theory. It would probably be very sophisticated.
      But the original question that began this thread seemed to broaden
the scope to include much simpler spreadsheets and simpler databases.
And that is why I answered as I did. It is also why I have written this.
The range of databases that can be created goes from the very simple to
the very complex.
      For some people, entering SQL statements in to the Execute SQL
Statement dialog is very easy to do. But doing this would be very
frustrating to to others because it is hard to tell whether they wrote
the write SQL or not. For them, using the dialogs of Base will provide
them with what they need.

--Dan

The problem appears to be when should a simple database be used in preference to a very messy spreadsheet. Spreadsheets are excellent for doing calculation intensive operations but not very good when dealing with scattered relational data. Databases are much better at handling data relationships with modest calculations.

For example one person company might initially find that using a spreadsheet to generate and track invoices fairly easy. Later it might become a problem to locate information in the spreadsheets but it would be much easier to generate the required data from a database. The question then becomes when does the spreadsheet fail as database. It is not question that always has an obvious answer.

Also, one should remember that many who do not use databases regularly fail to appreciate one major advantage; enter once and query and use as needed in many places and ways. Yes you can link to cells within a spreadsheet but if the data must be reused else where then you often cut & paste or worse yet retype the data in another spreadsheet.

--
Jay Lozier
jslozier@gmail.com


--
For unsubscribe instructions e-mail to: users+help@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.