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


On Tue, 2012-02-07 at 12:39 -0500, Jay Lozier wrote:
On 02/07/2012 11:51 AM, Nino Novak wrote:
On Tuesday 07 February 2012, Jay Lozier wrote:

Two related issues are a problem: spreadsheets are relatively easy to
set up and enter data with some inflexibility while databases harder to
set up and without the right front end tools some tricky to properly
enter data but are much more flexible.
As a consequence: It would help most, if the database set up barrier could be
lowered.

We therefore should ask (and try to learn) what makes database creation so
difficult, and how could we contribute to ease the learing curve?
I think the biggest barrier is not the tools to set up a database but 
the design process of setting up a database. Databases generally are 
design first then use while spreadsheets tend to be more design as you 
go. Databases require one to think more clearly about the data and how 
to model relationships within the data before one actually creates any 
tables, forms, etc. What is it I am trying to do with the data and how 
is the data best represented/stored/manipulated are questions that are 
often addressed in database design. The thinking about the data model is 
often a good exercise but one that can be skipped when using a 
spreadsheet as a database.

One problem is that people often want to jump in and start doing 
something when a little thinking should be done or how it should be 
done. Spreadsheets are easier to jump in and start with so often the 
planning is not done. Thus often spreadsheet users have databases that 
are nightmares because of poor data design. These are problems that are 
less common with databases because databases force more thought on data 
modeling.

IMHO, the real problem is that good data modeling is not usually taught 
to users and unless they start working with databases they never learn 
data modeling. Most books on using databases will, if briefly, discuss 
the concepts of data modeling and database design. I do not remember any 
book on a spreadsheet discussing it or even mentioning it.

Or directly: how can we make database creation easy and a low-threshold task?
I think some of the tools make the actual creation of a database 
reasonably easy though data importing is often a pain.

     This is a link to the Base Guide Ch 2, Planning/designing your
database. It is a draft document for OOo. The LO version is being
written right now. At least it is a beginning point when planning and
designing a database.
http://www.odfauthors.org/openoffice.org/english/userguide3/db3/dbg3_draft/planning-designing-your-database/view
 

--Dan 


(Just a thought)

Nino
who has never got familiar with databases "because of their complexity" (at
least from an innocent user's point of view). OTOH, I've never seen really
good tools for database creation (and change btw). So maybe, we could add to
database usability by creating Really Good Tools(TM) for creating, changing,
filling and quering databases.



-- 
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.