× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Some rambling thoughts...

Relational or non-relations solution?

Relational keeps it simple for development and maintenance. On the surface with the record counts you have provided, I don't see any performance issues because the tables will probably stay in memory most of the time, unless there is mammoth table growth or a massive transaction rate.

Byte or bit map approach probably means you are going to need to encapsulate all access and maintenance in callable routines, which probably makes the development effort greater. You could handle expandability by having the map field be variable length, adding new proteins to the end, but it would leave holes if a proteins was discontinued. I assuming each protein has a sequential number which is the index to a true/false byte in the variable field in two map files.
There would be no convenient SQL access without writing a UDT.

Ramblings may, or may not help.

Sam

On 12/10/2014 12:35 PM, James H. H. Lampert wrote:
On 12/10/14 10:13 AM, Monnier, Gary wrote:
For your scenario:

Two tables to define the meal..
One table for the meal (header) the protein/non-protein (must be
in the proteins master table).
- Tofu is a protein albeit not meat of any sort.
- The non-protein entry in the protein master may be described as
desired: maybe as Air or Protein-Free?
One table for the addition dishes for the meal (detail)
- dish type (starch, vegetable, etc.)
- dish ID (ID must be in the corresponding master table)

Keep in mind that the food analogy here is exactly that: an analogy.
We're not really talking about food here, except as a metaphor for the
real world situation (which I'm not at liberty to discuss). We can
assume that, for the sake of the analogy, the protein file has non-meat
records including (but not limited to) "tofu," "TVP," "Scrambled eggs,"
"overripe Limburger," "peanut butter," and "nothing at all."

And indeed, the food analogy breaks down on the conceit that only
certain starches and vegetables are compatible with any given protein.
If I want to have poultry dressing, Yorkshire pudding, and carrot mousse
with Spam piccata, it may be a weird combination, but it's certainly
possible. In the real world scenario, we can assume that dressing ONLY
goes with poultry dishes, and Yorkshire pudding ONLY goes with roast beef.

Now, the obvious answer to me, if everything were closed-ended, would be
either (1) to have a bitmap (or more likely byte-map) field in the
starch and vegetable fields, with one element for every protein,
indicating compatibility, or (2) to have two bitmaps in the protein
file, indicating the compatible starches and vegetables. The problem
with this is that it's inherently closed-ended, and even if some
expansion space were built into the bitmaps, it would be necessary to
change the structure if that expansion space were exceeded.

--
JHHL

---
This email has been checked for viruses by Avast antivirus software.
http://www.avast.com


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.