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

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 

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:
Posting guidelines + more:
List archive:
Privacy Policy:


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.