Base or Calc? Storing info where records will be added, but have to do math

Background: I used OOo a lot and same with LO, but not for a while, since I’ve been involved in a lot of activities that don’t happen at the computer. In the past I wrote a number of macros and even an application that used OOo’s API so my clients in that business could run a program that would use OOo to automatically generate printed material they needed. However, when I’m doing work in LO, like writing or making up a spreadsheet, I prefer to do as little programming as possible. So if this can be solved with spreadsheet functions, for instance, instead of writing code, that’d be great.

What I need to do: I have a number of pottery glaze recipes and want to store them. So far that would work in Base. BUT - I need to do calculations. For instance, if I have a simple recipe like this:

Clear glaze
Custer Feldspar: 20%
Silica: 20%
Wollastonite: 20%
Kaolin: 20%
Frit 3134: 20%

This one is simple and all the numbers add up to 100%, which is important for reasons I won’t go into here. But during testing, often the ingredient percentages get changed so I might end up with something like this:

Clear glaze
Custer Feldspar: 22%
Silica: 23%
Wollastonite: 18%
Kaolin: 20%
Frit 3134: 15%

Now it doesn’t add up to 100%. In a spreadsheet, it’s easy to add a function to refactor it and provide adjusted percentages in the next column over that use the same proportions and add up to 100%. So I need to do calculations like in Calc. Live updates are helpful so if, after a few years, I want to make a change, the refactoring will be done as I make the change.

Also, for different glazes I need to add different proportions of water. For some glazes, I might need 70 grams of water for every 100 grams of powders, and for others, maybe 80 grams of water. I want to be able to type into a field how much glaze I need for a batch and then have it (Calc, Base, whatever I’m using) figure out how many grams of each powder I need and how much water to add to get the size I want.

While I am starting with a fair number of recipes, I’ll be adding more continually.

Issues and Points of Consideration:

  • If I use Calc, I have to copy and paste a template table every time I add a new glaze it’s harder to find each glaze I enter than it would be in a DB program like Base. So adding glazes to Calc is harder and more distracting from the work I’m doing.
  • If I use Base, I need to be able to do the calculations without having to spend time working out whether to do it as a macro, write it in LO Basic (if that’s still the language used?), use the API, or something else. (I’d be using the LO default DB system - don’t want to take a long time learning and installing something else at this point.)
  • Base would make it easy to add extra fields for notes
  • It’s been a long time since I’ve used a DB program or coded for a DB, so I’ve forgotten a lot, but I think, in a DB, I’d have to come up with a maximum number of fields for ingredients, so I have room to include a lot in complex glazes. In Calc, I just add more rows to a table. If I allot a lot of fields, many will stay blank in some records and I don’t know how the system would handle those when doing calculations.

I’ve seen a few things on the web, including here, when I search for info on doing calculations in Base, but they’re old and I don’t know how outdated they are.

Base, of course.
ask128634.odb (20.8 KB)

with this and the other statement

I guess you already decided to use Calc.
But I try to give you an impression of your tasks:

Calculations can be done in both systems. Calc will use a second column and formulas per cell, in Base you will use an SQL statement for the column instead. Both will not change your entered values to give 100%, but show this separate. To change the original values one need a macro (or you use copy/paste for values manually in Calc).

Calc will react directly to entered values, if the formula exists.
Base may need a refresh button or a macro for this.

Not really. Adding rows is no problem, if your design is right. A typical database design would be two tables:
Idr, reciepie-name, topic. and
Idi, ingredients, Idr
where both tables are connected via Idr

No. Changing table design is more complicated in Base. In Calc you can write anything everywhere (and run in trouble later), while in Base you should decide early, if you need a single note-field per reciepie, then extend table to
Idr, reciepie-name, topic, note
or maybe have a third table
Idn, notes, Idr. to handle all notes.

Languages are not removed, so yes you can write in BASIC. But ther is also Python and Javascript, and you can interface to C, C++, Netbeans etc. (I even read some questions about Pascal/Lazarus here). For small stuff BASIC is the easiest start, but you are quiete free here…

No, just more used to Calc. Never used Base. Actually, other than things like address books, I don’t think I’ve used a DB program in years that is intended as a front end to a DB except what I’ve written in Python (or Perl - but that was way back!).

The 100% amounts - I figured that’d be in a 2nd column. But I’d want it to auto-update, so if I change the “raw” amount of a substance in my ingredients, the calc based on 100% would change automatically - without having to press a button to calculate it.

I’ve used SQL before. It’s not a problem, but how hard is it to set up a query to trigger and redo the math whenever certain fields are changed?

Actually, and I don’t know why this didn’t hit me before, yes, using a separate table for the ingredients would do that. I was just thinking as simple as I could - like one record per glaze. That trapped me into a limited view.

I guess I wasn’t clear. I can always add a table for notes, but I mean “add” as in adding that field at the start. Easier, at least from my limited experience view, to add a text field to allow a number of comments in a DB than in a spreadsheet. True, it can be done in a spreadsheet, but seems to me it’s easier to have that in a DB.

Python? Cool! When I was last using the API and doing programming, I could do BASIC or Java and use the API. I don’t think Python was even an option back then. (Pre-2010, OOo, not LO.)

How difficult is it to include Python code with the file so I can trigger it easily? Also, when I have done programming before, using BASIC (or the Java API), I remember the API was seriously difficult to learn. To select text in Writer or to do a find and replace, if I recall, took quite a few steps, like working with the main document object and having to figure out just what to use within that. Would it be difficult, in BASIC or Python, to trigger a function in the language when a field is changed, then to read that and other fields, do simple math, and update other fields?

(I don’t mind doing the research on HOW to do it - just don’t want to spend hours looking through all that only to find it’s much harder to setup than I thought, so I’m mainly concerned about if that’s hard to do - if it’s the kind of thing I can learn and setup in a few hours, that’s doable. This isn’t for work, and I’m not being paid to write it, so I don’t want to spend weeks and weeks on it.)

Thanks. Looking that over. Still don’t know enough about Base to look “under the hood.” I like that I can select things with a dropdown. I figure I can use SQL to write a form where I could select a glaze, then have the ingredients show up in a table, like you had the listing of minerals in a table?

And I couldn’t get into the nuts and bolts - need a bit of time, but what did you use to do the percentage calculations? (And how do I get to that?)

Sorry, the API is the same for all languages.
A newer option are the ScriptForge-Libraries. They add an additional layer on the API…

OO also has python, but imho the never managed the transition to python3, which is a showstopper. (But I should look this up again. Maybe AOO will surprise me…)
The main problem in old times was the need to put all scripts in the right places yourself, without any IDE. Now we have APSO, and some IDEs can be used to develop for LibreOffice…

You use it when posting to this forum, when doing online shopping, online banking, you do it all the time when you fill out some kind of form.

My demo has a list of minerals (names and ids only), a list of rocks (names and ids) and a table mapping minerals to rocks with the respective for each pair.
In addition, the 2 lists have a unique index on the names.

  • You can’t enter any name duplicates in either list.
  • You can’t enter duplicates of rock/mineral pairing.
  • Tools>Relationships shows the relations between the 2 tables with primary keys and their linked foreign keys.
  • There are 2 queries lbRocks and lbMinerals. They are designed to fill listboxes of rocks and materials.
  • Query “TotalPercents” gets the sums of percentages for each rock.
  • “Totals_adjusted” gets the adjusted percentages from the table using the percentages and the respective sums of query “TotalPercents”.
  • The current UI consists of 2 form documents mapping the rocks to minerals and vice versa.
  1. In the rocks form, you can enter new rocks (no duplicates possible) into the empty row behind the last one.
    – In the red table control you can add/edit/remove minerals and percents of the selected rock (no duplicates possible). Any mineral needs to be added to the table of minerals before it appears in the column of mineral list boxes.
    – The sum of percents and the table of adjusted percents update automatically. This part is linked to query “TotalPercents”.
    – The calculated table of adjusted percents is not editable and ordered descending by percentages. This part is linked to query “Totals_adjusted”.
  2. The minerals form shows the rocks where a selected mineral occurs.

No quirky array formulas, no lost references, no error values, no duplicates, no incomplete nor inconsistent data, no lookups, no dragging around of formulas. Everything is prepared with a set of rules and arithmetics carefully kept away from the user.
My co-workers use similar Base forms (networked, multi-user) since 15 years without any problems.

It’s exactly the other way round. Calc calculates value by value. Databases calculate entire fields.