John
On Thu, 2011-10-13 at 07:14 +0100, John Talbut wrote:
> Hi
>
> OK, let me go back to square 1.
>
> First of all I am not talking about a situation in which LibreOffice
> base needs to access data tables in separate files that use different
> database structures, e.g. one table is in MySQL and another is in
> PostgreSQL. This may be something that others need and I seem to recall
> that M$ access could do this but I do not need to.
>
> Next, terminology because "database" can mean a number of things.
> Please correct me if I am wrong here. The data are contained in tables.
> These can be simple tables such as CSV tables or more complex tables
> constructed according to the rules of a particular database application.
> These tables can be in separate files or they may be embedded along
> with other information.
CSV files are normally used for importing and exporting data into or out
of a database. Databases do not use csv or txt files otherwise.
>
> Then there are such things as queries, forms, reports and configurations
> which could, I guess, be each in separate files but are normally saved
> embedded together or with, say a data table. The results of running
> these, if saved, will be data tables or reports in separate files.
>
> Finally there is the database application which may be in one or many files.
>
> Now, to my situation. First of all I am using Debian GNU/Linux testing
> distribution. I use LibreOffice and for my database needs I use base.
> I use the built in HSQLDB database application and have my data tables
> embedded in the .odb file.
>
> This has worked adequately (clunkily I would say, but I will keep other
> difficulties out of this discussion). However, base has recently become
> unusably slow in response to something that has changed in openjdk (I
> have asked about this elsewhere).
There have been problems with various recent Java versions causing
performance problems. The work around to is use an earlier version of
Java.
>
> This has prompted me to revisit the question of whether to separate out
> my data tables. I am wondering whether it might be a workaround for the
> slowness problem. Also there may be advantages in backing up data
> separately and having it less vulnerable to anything going wrong in
> LibreOffice.
Backing up the data in a format that allows to reconstruct the database
at worst or just open the backup is always good practice. This can be
extended to backing up all data so one can restart if there is a
hardware failure.
>
> My data consist of a list of names, addresses etc. in one table and then
> some other tables that have additional information that only applies to
> (overlapping) subsets of the people in the names etc. table.
I am not sure about your design. There is procedure used with databases
called normalization. The idea is to group similar data into separate
tables with use of primary and foreign keys to allow linking. For
example, one would have a table of vendor addresses, another of vendor
contacts, another of vendor payment information, etc. Each table would
have its own primary key (often an integer) and relationships with the
other tables use a foreign key that is same as the primary key in the
other table. Appropriate normalization tries to isolate different types
of data into logical groups that allows easier data maintenance, access,
and understanding of the relationships between the data.
One can study data modeling and database design independent of the
database application, the normalization procedure is not dependent on
the applicaton. A good design for a specific situation will be
implemented similarly in any database application.
>
> Way back in the past I used M$ access to handle these data. At that
> time my data tables were each in a separate file and everything worked
> very well.
>
> When I moved over to OpenOffice.org I found that this was no longer
> possible. In order to run queries using data from different tables (all
> using the same database structure) I found I needed to embed all the
> tables into the same .odb files.
>
> So my question is, is this still the same in LibreOffice?
>
> More specifically, is it possible only using base, i.e. without running
> a separate database application, to access, run queries across and
> manipulate the data in data tables contained in separate files? I am
> assuming the these would probably be HSQLDB data tables.
>
> If not, would it be possible if the data tables were embedded in the
> same file?
>
> If either of these are possible then some pointers to how to separate
> out the data tables would be helpful.
>
> Kind regards
>
> John
>
>
To clarify a few points, in most database applications the database
consists of a group of tables with related data with other constructs
such as views, functions, etc that are used with the database. Within
the database, data in different tables can be accessed by the use of SQL
joins, unions, and subqueries.
For example a query between the Vendors table and Invoices table in an
account payable (Accounts) database could look like:
SELECT invoiceID, Amount, DueDate, Name, Address, City, State, Zip
--these the columns from the two tables
FROM Invoices --the base table
JOIN Vendors --the external table
ON Invoices.VendorID = Vendors.ID --the relationship
between the tables (one primary key and one foreign key)
The above syntax for what is called an inner join should work in all
database applications with a database. If the tables are in different
databases, you might access the data using "schema qualified names"
where the schema name is the database (Accounts.Vendors or similar
syntax).
If you are using the GUI to construct the query, the final generated
query will be similar to above.
--
Jay Lozier
jsloz...@gmail.com
--
For unsubscribe instructions e-mail to: users+h...@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
