Generating and storing lists of variable lengths?

8 vues (au cours des 30 derniers jours)
Andrew M
Andrew M le 23 Juil 2021
Commenté : dpb le 27 Juil 2021
I'm trying to create an app that allows you to enter information about a food recipe with variables for the name, instructions, nutrition facts (calories, fat, etc. - all stored in separate variables). These recipes would be stored in a file (xls?) and could be accessed later by a different app that would manipulate the data.
The issue I'm having - since recipes have different numbers of ingredients, I am running into trouble making a function that stores each ingredient in a way that makes them easily accessible later.
  • I am using writecell with 'WriteMode' 'append' (so that each new recipe is stored beneath the last on the spreadsheet)
  • However, since ingredients are stored in a cell, it will not allow me to store nested cells
  • To remedy this I then tried 'strjoin(ingredients)' which worked and gave one value that represented all ingredients in each recipe. However, doing it this way will make it very difficult to find the values later.
  • Another thing I tried was attaching a tag to each ingredient (e.g., ,&bananas,&oranges). My idea here was that I could then search the list for all instances of ",&" and arrive at the ingredients. However, this won't differentiate which recipe the ingredient belongs to, since the recipe list is becoming a 300+x1cell that's just a long line of these values.
Essentially where I'm stuck is that I am generating cells with varying lengths and unsure of the best way to store these into a database for later reference.
  9 commentaires
dpb
dpb le 25 Juil 2021
save recipes names ingredients quantities units ...
NB:
Remember you can put the variable names in a set of variables and then use the function form for save, too...so it is possible to localize those in the code preamble and only modify in the one location.
Or, if you were to prefix each name with 'rec_' or somesuch, then the wildcard expression would let you write simply
save recipes rec_*
This adds a little more typing in the reference in using the variables, but has the above advantage plus perhaps a secondary one of distinguishing between temporary and permanent variables in the coding.
It's a poor man's substitute for the struct as an organizing element, but retains the straight addressing without the complexities of trying to write the generic structure dereferencing expressions.
Andrew M
Andrew M le 26 Juil 2021
After taking your advice I rewrote it such that with each iteration, there are two files being saved, both structs:
One is simply a list of the names of recipes:
recipenames =
struct with fields:
recipenames: {'first recipe' 'taco'}
Second is a struct containing:
a.recipe
a = load('taco.mat');
a.recipe
ans =
struct with fields:
name: 'taco'
recipeinst: 'stir'
ingredients: {'taco' 'water'}
qty: {[2] [2]}
measure: {'piece(s)' 'tbps'}
calories: 10
totalfat: 2
cholesterol: 3
sodium: 4
carbs: 2
fiber: 3
sugar: 42
protein: 2
This approach has the advantage of allowing the app to quickly reference the "recipenames" list to see if it exists. If it does, it can then load the .mat file with the corresponding name.
The downside to this approach would be: if there are hundreds of recipes, that would mean hundreds of recipe .mat files, which I imagine could get boggy.

Connectez-vous pour commenter.

Réponse acceptée

Jeff Miller
Jeff Miller le 23 Juil 2021
There isn't really a good solution to this type of problem with "flat file" databases, but relational databases handle it very gracefully if you can go that route. A relational database for your situation would require (at least) three tables: one for listing the distinct recipes, one for listing the distinct ingredients, and--crucially--a third "link" table. Each row in the link table connects one recipe to one ingredient, so each recipe can have as many rows in the link table as it needs (i.e., one for each ingredient), and each ingredient has as many rows in the link table as it needs (i.e., one for each recipe that it belongs to).
  2 commentaires
Andrew M
Andrew M le 26 Juil 2021
Although @dpb's replies in the above chain ended up helping me the most and were the fastest for a limited dataset, for some reason I'm not able to accept that as an answer. Nevertheless after reading up, building a relational database would be the more robust approach for a larger dataset. Thank you!!
dpb
dpb le 27 Juil 2021
'Cuz none of mine were actually Answer; just comments...I didn't really have an Answer; just some thoughts along the way... :)

Connectez-vous pour commenter.

Plus de réponses (0)

Produits


Version

R2021a

Community Treasure Hunt

Find the treasures in MATLAB Central and discover how the community can help you!

Start Hunting!

Translated by