Base

Hi :slight_smile:

I think we should avoid writing any documentation for Base. I have kept trying
to encourage people and draw in people that seemed keen to do some but now i
agree that we should abandon any effort on it. It seems that TDF is not going
to do anything to support Base so there is no point in documentation for it.
Apparently most linux users prefer PostgreSQL or MySQL/MariaDB (or Drizzle on
the Cloud) so it seems we should point people to those rather than Base.

Regards from
Tom :slight_smile:

Hi Tom,

Hi :slight_smile:

I think we should avoid writing any documentation for Base. I have kept trying
to encourage people and draw in people that seemed keen to do some but now i
agree that we should abandon any effort on it. It seems that TDF is not going
to do anything to support Base so there is no point in documentation for it.
Apparently most linux users prefer PostgreSQL or MySQL/MariaDB (or Drizzle on
the Cloud) so it seems we should point people to those rather than Base.

I don't understand your reasoning? Why wouldn't you want to write documentation for Base? You still need documentation, if you want to use Base as a frontend to connect to one of those databases that you mentioned. So, in my opinion, there is some need for user docs. We should definitely tell people, that the built-in database is not really secure, but that they can choose any other database they like.

So, definitely not dropping.

(My opinion, of course.)

Sigrid

I was under the impression that some (or much?) of LibreOffice Base
doesn't work, so people get very frustrated in trying to use it. Is that
true? Or is the problem only with the built-in database, but Base works
fine as a front-end to other d/b? If the latter, then yes we should
certainly document how to use it as a front-end to other databases... if
we can find people with the knowledge and time to write that
documentation.

--Jean

Hi :slight_smile:
I have been getting the same impression of Base as Jean. Apparently Base has
different unpredictable flaky quirks in different releases. There appear to be
too many complex issues for any of it to be sorted out in a reasonable
time-frame.

Regards from
Tom :slight_smile:

Jean, Tom, Sigrid

> Hi Tom,
>
>
> > Hi :slight_smile:
> >
> > I think we should avoid writing any documentation for Base. I have kept trying
> > to encourage people and draw in people that seemed keen to do some but now i
> > agree that we should abandon any effort on it. It seems that TDF is not going
> > to do anything to support Base so there is no point in documentation for it.
> > Apparently most linux users prefer PostgreSQL or MySQL/MariaDB (or Drizzle on
> > the Cloud) so it seems we should point people to those rather than Base.
> >
>
> I don't understand your reasoning? Why wouldn't you want to write documentation for
> Base? You still need documentation, if you want to use Base as a frontend to
> connect to one of those databases that you mentioned. So, in my opinion, there is
> some need for user docs. We should definitely tell people, that the built-in
> database is not really secure, but that they can choose any other database they like.
>
> So, definitely not dropping.
>
> (My opinion, of course.)
>
> Sigrid
>

I was under the impression that some (or much?) of LibreOffice Base
doesn't work, so people get very frustrated in trying to use it. Is that
true? Or is the problem only with the built-in database, but Base works
fine as a front-end to other d/b? If the latter, then yes we should
certainly document how to use it as a front-end to other databases... if
we can find people with the knowledge and time to write that
documentation.

--Jean

I have been testing MariaDB, a recent fork of MySQL. It can be the back
end for Base and you can set up Base to talk to it once you get the
correct connectors installed. The connection is easier using JDBC than
ODBC.

Let work on it some I will get something together showing how to use
Base with MySQL/Maria and later PosgreSQL, If we do this we may want to
give some instructions on setting up the back end database. I have found
the overall documentation quality rather poor for MySQL. They assume you
are intimately familiar with your system so they refer to default
location without telling one what the default location is.

Someone bug this weekend about looking at this in more detail.

Blimey again!

Documentation about that might be really useful. Preferably focussing on
MariaDb (imo) rather than MySql if that makes any difference. Good work Jay,
thanks :slight_smile:

Regards from
Tom :slight_smile:

Tom and all,

I'm new to Base, but have been using it intensely for a number of weeks now, most lately with that java reversion we talked about a little while back. It's fast, and crisp, and just works. No burps yet.

All I can say is that is works fine for me, and is more stable than the MS Access version I worked with for years. I remain concerned about TDF's abandoning it, with the result that it slowly falls apart with each release, but right now I don't have a complaint.

I'm planning to try using it as interface to an sqlite backend very soon, as that engine will surely meet my needs. MarionDB certainly looks interesting, but the real issue for me isn't the db engine but the interface. I need to be able to design and run forms. If I don't use Base to do this, what else is there in the opernsource world? I keep looking, and so far simply haven't found anything. Am I the only one with this need?

I'm a bit baffled by the database engines that present themselves to the world bare. Apparently one just writes one's own interface for them, yes? For the non- IT-professional this is essentially a non-starter. I simply don't have the time.

Any thoughts on this, anyone?

Tom

Arrrrg! MarionDB? No such animal. Make that MariaDB. Sorry. ~t.

Tom

> Hi :slight_smile:
> I have been getting the same impression of Base as Jean. Apparently Base has
> different unpredictable flaky quirks in different releases. There appear to be
> too many complex issues for any of it to be sorted out in a reasonable
> time-frame.
>
> Regards from
> Tom :slight_smile:
>
>
>
>
> ________________________________
> From: Jean Hollis Weber<jeanweber@gmail.com>
> To: documentation@global.libreoffice.org
> Sent: Tue, 2 August, 2011 0:08:31
> Subject: Re: [libreoffice-documentation] Base
>
>> Hi Tom,
>>
>>
>>> Hi :slight_smile:
>>>
>>> I think we should avoid writing any documentation for Base. I have kept
>> trying
>>
>>> to encourage people and draw in people that seemed keen to do some but now i
>>> agree that we should abandon any effort on it. It seems that TDF is not
>> going
>>
>>> to do anything to support Base so there is no point in documentation for it.
>>> Apparently most linux users prefer PostgreSQL or MySQL/MariaDB (or Drizzle on
>>> the Cloud) so it seems we should point people to those rather than Base.
>>>
>> I don't understand your reasoning? Why wouldn't you want to write documentation
>> for
>> Base? You still need documentation, if you want to use Base as a frontend to
>> connect to one of those databases that you mentioned. So, in my opinion, there
>> is
>>
>> some need for user docs. We should definitely tell people, that the built-in
>> database is not really secure, but that they can choose any other database they
>> like.
>>
>>
>> So, definitely not dropping.
>>
>> (My opinion, of course.)
>>
>> Sigrid
>>
> I was under the impression that some (or much?) of LibreOffice Base
> doesn't work, so people get very frustrated in trying to use it. Is that
> true? Or is the problem only with the built-in database, but Base works
> fine as a front-end to other d/b? If the latter, then yes we should
> certainly document how to use it as a front-end to other databases... if
> we can find people with the knowledge and time to write that
> documentation.
>
> --Jean
>
>
Tom and all,

I'm new to Base, but have been using it intensely for a number of weeks
now, most lately with that java reversion we talked about a little while
back. It's fast, and crisp, and just works. No burps yet.

All I can say is that is works fine for me, and is more stable than the
MS Access version I worked with for years. I remain concerned about
TDF's abandoning it, with the result that it slowly falls apart with
each release, but right now I don't have a complaint.

I'm planning to try using it as interface to an sqlite backend very
soon, as that engine will surely meet my needs. MarionDB certainly looks
interesting, but the real issue for me isn't the db engine but the
interface. I need to be able to design and run forms. If I don't use
Base to do this, what else is there in the opernsource world? I keep
looking, and so far simply haven't found anything. Am I the only one
with this need?

I'm a bit baffled by the database engines that present themselves to the
world bare. Apparently one just writes one's own interface for them,
yes? For the non- IT-professional this is essentially a non-starter. I
simply don't have the time.

Any thoughts on this, anyone?

Tom

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Tom Cloyd / tc@tomcloyd.com / (435) 272-3332

MarianDB uses MySQL so it will connect to Base using the MySQL ODBC/JDBC
methods.

OK, sure, and I fully realized that. But, what do people do who don't use Base? I presume they write their own interface for each application. Am I wrong? I'm talking here not about queries and the like, but about forms, with subforms displayed on the page. Being able to do this with Base makes for quick progress to a usable db. Without Base...what is there except SQL and the command line...and writing your own GUI? THAT was one of my questions.

Secondly, using Base as the interface has an inherent problem, as I tried to suggest: if it's not being maintained, at some point, with a new release of LO, it breaks. I'm trying to figure how to plan for this...

Tom

Yesterday I was afraid to start a flame, but I think that what I think is
the discussion line....

why TDF don't cares about Base? May be you think that users don't care about
it, but it's not true, that is only aplicable to "linux users", or
"experienced users". I know a lot of people that don't want to use
OpenOffice or LibreOffice because Base don't supply their needs, they can't
port ther MS Access databases directly, but the situation is worse: they
can't make (from scratch) new databases in a easy way with Base, while yes
with MS Access.

A lot of people don't know a lot of programming, but knows the minimum to
create consistent databases with this type of software, and this same people
don't want to pay another developer to make specific software with a lot of
different technologies groupped together (mysql, and maybe qt, or gtk, or a
web frontend made in php....). In little business, the people can't waste
their time creating "perfect" information management systems, many times
they have 1 only computer and it's a critical point the ability to make
backups of the database copying one single file in a usb pendrive in one or
two steps.

Sometimes seems that TDF forgets these people, I've read months ago
something like "that can be done with... [here you should write a pipeline
of chained applications, more than 4], it's a waste of time doing this
software (a program I propposed)". When i received that answer i understood
why people scares about linux and free software, because this type of
reasonings... thinks the whole TDF in the same way? U_U

Hi,

My 2 cents would be that Base is an important asset for LibreOffice.
It may have its fragilities at the moment, but I feel that it should
definitely be kept in the suite and that we should still work on
documentation for it.

I'm trusting that the project is going to, at some time hopefully
soon, acquire some devs to work on it. After all, all of the
components of LibreOffice can be improved in some way or other, but
they're all progressively getting attention.

Base's turn will come, too.

Hi :slight_smile:
There is no plan. No effort is being made to attract people to it and no plan
to do that. No thought given to why devs and others avoid it even if they
started out being keen to work on it.

The greatest amount of support Base gets is from a couple of people that hope
that someday there might be some improvement. Hoping that pigs might fly
doesn't make it happen.

I think that makes it score 1/10 on a scale of something worth migrating to.
The 1 is because it works really quite well for most people most of the time
right now.

It is great to see people on the Users mailing list;
1. giving coding patches in answer to individual problems
2. helping regression test java and other dependencies
3. helping users switch from one back-end that 'should' work (but is broken) to
another that does work.

These are not trivial issues that the average office worker is likely to be able
to solve without a lot of hand-holding and intensive step-by-step help in the
Users list. People experienced with MS Access are not used to having to deal
with those sorts of problems.
Regards from
Tom :slight_smile:

I remain concerned about TDF's abandoning it, with the result that it slowly falls apart with each release,

For all practical purposes, the database component of OOo was treated
like the red haired stepchild. Under the TDF, LibO has simply continued
that mistreatment.

I'm planning to try using it as interface to an sqlite backend very soon, as that engine will surely meet my needs.

When the discussion about which _additional_ database engine OOo should
include. HSQLDB won, and SQLite lost. From my POV,the only reason HSQLDB
won, was because it used Java. At the time, it was technically inferior
to SQLite.

In an ideal world, there would be an extension that installs SQLite as
if it were built into LibO, and provide a usable UI for database
creation, editing, and viewing.

but the real issue for me isn't the db engine but the interface.

This relates to who creates databases.

There is a lot of useful theory, and practice in database construction
and maintenance. For most projects, applying that theory would be
helpful. Which is why database designers are very reluctant to allow
non-database designers to create databases. Or, more bluntly, don't
like pre-built tools that non-database designers can use, to create, and
use databases.

The simple reality is that when there is not an obvious, easy way to
construct a database, people will use spreadsheets, blithely ignoring
the fact that spreadsheets can, and will destroy their data. Then, since
most people use spreadsheets instead of databases, development of
database tools for Joe Sixpack gets lowered in priority, eventually
reaching the point that databases for mortals are considered irrelevant.

I need to be able to design and run forms. If I don't use Base to do

this, what else is there in the opensource world?

PERL, Python, Ruby, etc.

I'm a bit baffled by the database engines that present themselves to the

world bare. Apparently one just writes one's own interface for them,

Historically, database engines have shipped without an interface. The
user was expected to write their own UI. This presents the fewest
restrictions on the database designer.

By way of example:
I create resources for various Bible study programs. These all use
databases for the content. With a generic UI, I can't force record 31102
to be Revelation 22:21, or validate Vulgate versification as it is
entered. With a custom UI, Vulgate versification can be input, and the
data automatically converted to KJVA versification.

For the non- IT-professional this is essentially a non-starter.

Database designers are the last hold out in the IT World, thinking that
they are gods, and nobody else is pure enough to do what they do.

All that said, I do think that a manual that focuses on using the Base
component as a front end to PosgreSQL, MySQL, Mariadb, Drizzle, MS
Access, etc. A second manual, focusing exclusively on SQLite might be
justified.

jonathon

Jonathon,

> I remain concerned about TDF's abandoning it, with the result that it slowly falls apart with each release,

For all practical purposes, the database component of OOo was treated
like the red haired stepchild. Under the TDF, LibO has simply continued
that mistreatment.

> I'm planning to try using it as interface to an sqlite backend very soon, as that engine will surely meet my needs.

When the discussion about which _additional_ database engine OOo should
include. HSQLDB won, and SQLite lost. From my POV,the only reason HSQLDB
won, was because it used Java. At the time, it was technically inferior
to SQLite.

In an ideal world, there would be an extension that installs SQLite as
if it were built into LibO, and provide a usable UI for database
creation, editing, and viewing.

> but the real issue for me isn't the db engine but the interface.

This relates to who creates databases.

There is a lot of useful theory, and practice in database construction
and maintenance. For most projects, applying that theory would be
helpful. Which is why database designers are very reluctant to allow
non-database designers to create databases. Or, more bluntly, don't
like pre-built tools that non-database designers can use, to create, and
use databases.

The simple reality is that when there is not an obvious, easy way to
construct a database, people will use spreadsheets, blithely ignoring
the fact that spreadsheets can, and will destroy their data. Then, since
most people use spreadsheets instead of databases, development of
database tools for Joe Sixpack gets lowered in priority, eventually
reaching the point that databases for mortals are considered irrelevant.

> I need to be able to design and run forms. If I don't use Base to do
this, what else is there in the opensource world?

PERL, Python, Ruby, etc.

> I'm a bit baffled by the database engines that present themselves to the
world bare. Apparently one just writes one's own interface for them,

Historically, database engines have shipped without an interface. The
user was expected to write their own UI. This presents the fewest
restrictions on the database designer.

By way of example:
I create resources for various Bible study programs. These all use
databases for the content. With a generic UI, I can't force record 31102
to be Revelation 22:21, or validate Vulgate versification as it is
entered. With a custom UI, Vulgate versification can be input, and the
data automatically converted to KJVA versification.

>For the non- IT-professional this is essentially a non-starter.

Database designers are the last hold out in the IT World, thinking that
they are gods, and nobody else is pure enough to do what they do.

All that said, I do think that a manual that focuses on using the Base
component as a front end to PosgreSQL, MySQL, Mariadb, Drizzle, MS
Access, etc. A second manual, focusing exclusively on SQLite might be
justified.

jonathon
--
If Bing copied Google, there wouldn't be anything new worth requesting.

If Bing did not copy Google, there wouldn't be anything relevant worth
requesting.

                              DaveJakeman 20110207 Groklaw.

MS access is not available expect over a network for Linux users. I
agree with you on manuals for using Base as a front end.

Johathan,

Briefly, this is the reply I was hoping for but not expecting. You know more than I, but what I know confirms what you say. WONDERFUL reply. Thanks so much.

So, now I will do this:

Go forward with using Base as frontend to sqlite (which looks really wonderful, and has a nice admin. addon available in Firefox), and use it as long as Base works.

And...go forward on my own with Ruby/sqlite project, constructing the sort of kludgy-but-very-functional commandline interface I've already done with my personal entity/relationship db experiments. Primitive, but damn well works, and not dependent upon anything I can't count on. The key to is constructing a domain specific language (easy with ruby), reserving direct SQL access for rarely encountered needs (as is normally done), and do output and input via text files. No pretty GUI, but real results for sure. I can live with this, AND it just might be useful to other people.

Sad what you say about the database design community, but all too true. They have no place for informed amateurs like me, and since there aren't many of me, we just don't count.

Spreadsheets as an alternative? May the gods preserve us from that dark day...

Tom

Hi,

Hi :slight_smile:
There is no plan. No effort is being made to attract people to it and no plan
to do that. No thought given to why devs and others avoid it even if they
started out being keen to work on it.

The greatest amount of support Base gets is from a couple of people that hope
that someday there might be some improvement. Hoping that pigs might fly
doesn't make it happen.

I think that makes it score 1/10 on a scale of something worth migrating to.
The 1 is because it works really quite well for most people most of the time
right now.

It is great to see people on the Users mailing list;
1. giving coding patches in answer to individual problems
2. helping regression test java and other dependencies
3. helping users switch from one back-end that 'should' work (but is broken) to
another that does work.

These are not trivial issues that the average office worker is likely to be able
to solve without a lot of hand-holding and intensive step-by-step help in the
Users list. People experienced with MS Access are not used to having to deal
with those sorts of problems.
Regards from
Tom :slight_smile:

________________________________
From: David Nelson <lists@traduction.biz>
To: documentation@global.libreoffice.org
Sent: Fri, 5 August, 2011 10:30:21
Subject: Re: [libreoffice-documentation] Base

Hi,

My 2 cents would be that Base is an important asset for LibreOffice.
It may have its fragilities at the moment, but I feel that it should
definitely be kept in the suite and that we should still work on
documentation for it.

I'm trusting that the project is going to, at some time hopefully
soon, acquire some devs to work on it. After all, all of the
components of LibreOffice can be improved in some way or other, but
they're all progressively getting attention.

Base's turn will come, too.

--
David Nelson

--
Unsubscribe instructions: E-mail to documentation+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/documentation/
All messages sent to this list will be publicly archived and cannot be deleted

My experience, unscientific observations, is that most users avoid any
true database whenever possible for routine uses and will use a
spreadsheet. To use any database well requires more design and knowledge
than simply slapping together a spreadsheet. A good database design must
answer several design questions, very similar to software design.
Essentially, a well designed database models logical groupings and the
relationships between the groups within the data thus making easier to
maintain and access.

SQL is not particularly hard to learn if you have some programming
experience but difficult for non-programmers. Queries are often very
straight forward but SQL requires accurate obedience to its syntax rules
much like a programming language.

Hi,

Hi,

> Hi :slight_smile:
> There is no plan. No effort is being made to attract people to it and no
plan
> to do that. No thought given to why devs and others avoid it even if
they
> started out being keen to work on it.
>
>
> The greatest amount of support Base gets is from a couple of people that
hope
> that someday there might be some improvement. Hoping that pigs might fly
> doesn't make it happen.
>
>
> I think that makes it score 1/10 on a scale of something worth migrating
to.
> The 1 is because it works really quite well for most people most of the
time
> right now.
>
>
> It is great to see people on the Users mailing list;
> 1. giving coding patches in answer to individual problems
> 2. helping regression test java and other dependencies
> 3. helping users switch from one back-end that 'should' work (but is
broken) to
> another that does work.
>
> These are not trivial issues that the average office worker is likely to
be able
> to solve without a lot of hand-holding and intensive step-by-step help in
the
> Users list. People experienced with MS Access are not used to having to
deal
> with those sorts of problems.
> Regards from
> Tom :slight_smile:
>
>
>
>
> ________________________________
> From: David Nelson <lists@traduction.biz>
> To: documentation@global.libreoffice.org
> Sent: Fri, 5 August, 2011 10:30:21
> Subject: Re: [libreoffice-documentation] Base
>
> Hi,
>
> My 2 cents would be that Base is an important asset for LibreOffice.
> It may have its fragilities at the moment, but I feel that it should
> definitely be kept in the suite and that we should still work on
> documentation for it.
>
> I'm trusting that the project is going to, at some time hopefully
> soon, acquire some devs to work on it. After all, all of the
> components of LibreOffice can be improved in some way or other, but
> they're all progressively getting attention.
>
> Base's turn will come, too.
>
> --
> David Nelson
>
> --
> Unsubscribe instructions: E-mail to
documentation+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/documentation/
> All messages sent to this list will be publicly archived and cannot be
deleted

My experience, unscientific observations, is that most users avoid any
true database whenever possible for routine uses and will use a
spreadsheet. To use any database well requires more design and knowledge
than simply slapping together a spreadsheet. A good database design must
answer several design questions, very similar to software design.
Essentially, a well designed database models logical groupings and the
relationships between the groups within the data thus making easier to
maintain and access.

SQL is not particularly hard to learn if you have some programming
experience but difficult for non-programmers. Queries are often very
straight forward but SQL requires accurate obedience to its syntax rules
much like a programming language.
--
Jay Lozier
jslozier@gmail.com

My experience: Not only spreadsheds are used by unexperienced people, even
when they don't know SQL. An example: my fathers (mother and father) learned
to use MS Access many years ago (arount 15 years), and designed many
databases for friends and other people (as a "job", they earned money).
Their first databases were .. hummmm... crap, but, hey!, those databases
were better than the older software of their clients! O_O , they learned VB
macros slowly, and making a lot of crappy designs (today they only know a
very little subset of SQL). Well, at this moment I know a minimum of three
databases made by they that are still running today, In my opinion these
three databases are the worst crap i ever saw, but their users are happy
with them -_- , happier than if they had to use only spreadsheeds, because
their needs are too complex for only using spreadsheeds.

More examples? My best friend started to work in Seat (a spanish automotion
company, part of WV), in theory as a junior mechanic engineer... but, wow!,
his boss ordered him to make a MS Access database ... he didn't know
anything about database design, but he could do the job in a reasonable time
(ok, it was the BIGGEST CRAP i saw in my life, but worked... another time).
In Seat they don't use LibreOffice or OpenOffice because Base is not really
usable while MS Access, even if it's horrible, is working as they expect.

More: In the Faculty of Economics and Bussiness of the University of
Barcelona... the same, they don't use LibreOffice or OpenOffice because they
are tied to MS Access (and... uff, to SAP :s ) ... (they have a "hole" of 45
millions of euros, they don't like to pay for licenses, they pay because
it's their "only" option... they don't know any other way of doing the
work). In this case... I'm working to break many of these dependencies, I'm
working on an online platform (with PHP and MySQL) to manage many of their
crappy issues, but I'm only a scholarship holder in a little department.

Even if you don't believe it, people will learn to design databases without
knowing theory if they have to do a lot of databases, and this (little)
practical knowdlege may be the difference between having to pay a lot of
money to an external developer or having the possibility to solve the
problems without external help.

Why I think it's important Base? because it's potential integration with
Writter and Calc , because when it's needed to make reports, and graphs,
it's possible to export them as ODF documents, or to "print" them as PDF
files... that's not a "trivial" task with other software stacks. And because
the familiarity of users with "old" tools as MS Access, and the possibility
to work without servers, and moving the data between computers using a
single file (in many cases, I know that it's not true all the time).

Go forward with using Base as frontend to sqlite (which looks really

wonderful, and has a nice admin. addon available in Firefox), and use it
as long as Base works.

The only thing that _SQLite Manager_ is good for, is eye candy.
Databases can only have one table, and there is a limit on both the
number of fields, and number of records it can hold.

The major problem with the SQLite extension for OOo, was that it wasn't
updated. Changes in either SQLite or the Base component were not
incorporated into the extension.

Arguably, a minor issue is/was that it relied on the Base component for
the UI. Something that doesn't work to well, when dealing with binary
blobs as data.

The key to is constructing a domain specific language (easy with ruby),

reserving direct SQL access for rarely encountered needs (as is normally
done), and do output and input via text files. No pretty GUI, but real
results for sure. I can live with this, AND it just might be useful to
other people.

That pretty much is the simplest way for Joe Sixpack to get data into a
database, when all they want to do, is have their data in a database.

The last time I saw a database front end that required virtually nothing
of the user, was for a shareware clone of dBase 3 that was out of Redmond.

Sad what you say about the database design community, but all too true.

They do have valid points. However, for the typical database used by
Joe Sixpack, the only data normalization that is needed, is that the
correct data is put in it in the first place.

Spreadsheets as an alternative? May the gods preserve us from that dark

day.

The Human Genome Project is just one major scientific research,f or
which all the data can be rejected off the bat as invalid, because of
known data destruction by Excel.

jonathon