[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [libreoffice-users] Base/HSQL table with more than two dimensions?

On 2020-06-24 08:40, Dan Lewis wrote:
A lectionary is an ordered set of readings, typically using a cycle of three or more years, to cover the Bible. In a four-year cycle the years are simply designated {A,B,C,D}, and for each day in a year readings are prescribed from different parts of the Bible. For any year, storing the readings in a database table is straightforward in two dimensions [fields (readings) x records (days)], and it is simple to SELECT the set of readings (usually from four different fields) for any day.

Obviously it is possible to do this in one table per year (say, four tables for four years), but since the pattern of records and fields is the same for all years, that is clumsy and should be unnecessary. It should be possible to do a table of three dimensions, of which the third dimension is the year {A,B,C,D} in the cycle, so that one could compare the readings for any given day across all years. But I don't see how to extend tables into three (as in this case) or more dimensions. Can someone point me in the right direction?  [It seems like this kind of database design issue should be common to a lot of domains.]

What I see, you are talking about three tables which contain data: readings, days, and years. A fourth table should be created containing three foreign keys for these three tables. What you need for this data is a relational database which Base can create. Just make sure you normalize these tables. You might want to read up on relational databases to see how to do this.

Actually, Dan, it's not that ambitious: the table contains not the readings, but a set of indices (keys) to the readings, one index/key per column (with each column/field drawn from a particular set of books of the Bible). Each row/record is for one day, and the day also modified by the year in the cycle of readings. That's why Dave Howorth's answer was right: just add one column for every added dimension (in this case, that added dimension being the year in the cycle).

The main reason it does not make sense to go further is a procedural one that predates [you think? ;-)] computer generation of these things. The lectionary bounds the list of readings by day, but does not necessarily determine it; often a choice will be offered, and a person must make that choice.

Then that reduced/approved set is used to fetch (with some string processing) the actual readings for print. Where there is a choice, the full set could also be used to fetch the optional readings to assist the person making the choice, but that gets into how much you want to impose computerized methods on a person who is not (yet, at least) so inclined. [No project is without non-technical constraints, which is fine; the purpose is to help with a solution, not impose one.] On the whole, this project has much that is relational (~20 completely normalized (third form) tables, relationally connected). It's just not particularly relational in this function.

I appreciate your thinking about it,

To unsubscribe e-mail to: users+unsubscribe@global.libreoffice.org
Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette
List archive: https://listarchives.libreoffice.org/global/users/
Privacy Policy: https://www.documentfoundation.org/privacy

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.