Re: Square pegs in round holes

"Graham Bellamy" <dontwriteme_at_ask.first.com> wrote in message news:<ac91i1$d94$1_at_perki.connect.com.au>...
> "Mikito Harakiri" <mikharakiri_at_yahoo.com> wrote in message
> news:bdf69bdf.0205181840.7252168b_at_posting.google.com...
>
> > Type Thickness(mm) Ratio(Sqm*mm/L) ContainerSize(L) TotalVolume(L)
> > Cost($/L)
> > Primer 1 0.99 20 40
> > 0.50
>
> I don't understand how your (Sqm*mm/L) is functioning.
> My Sq.m/L/mm is Square Meters per Litre for every 1mm thickness laid down.

If you spill 1L of water into the area of 1 Sq.m what the depth of the pool would be?  

Identity 1/1/mm == 1mm is the other way to see that your Sq.m/L/mm unit must be the same as mine Sqm*mm/L. Now, obviously, 1 Sqm*mm= 1 L, so that the units we are considering is in fact just some factor. Let me know if your Sq.m/L/mm value could ever be greater than one.  

> > Having all data in uniform units has some added benefits. For example,
> > you'll be able to query if all your materials fit into 14' truck.
>
> In the entry form, would it be advisable to base it on a query that calculates the uniform
> value, eventhough it won't be showing it on that form, such that any future queries simply
> pluck that field out at will?

I dont understand the last sentence.  

> > > For convenience of standardising calculations, should I force the user to
> > > enter Rate in a certain format (eg. L/Sq.m instead of Sq.m/L - user uses
> > > both, depending on how it's written on the bottle). I've read it's not a
> > > good idea to make the user conform for my benefit.
> >
> > There is neither L/Sq.m nor Sq.m/L in my proposed data model. 1 L/Sq.m
> > = 1 mm and that's Thickness. Now, I'm not saying that the user
> > necessarily have to be aware of that. Your application suggests to the
> > end user entering either L/Sq.m, or Sq.m/L and then it translates it
> > to canonical units and stores it.
>
> I'm not sure what you mean by '1 L/Sq.m = 1 mm'.

See the problem about spilled water.

> My model requires one field (thickness)
> to be mm, and another (Rate) to be [Sq.m/L or Sq.m/kg or Sq.m/L/mm or Sq.m/kg/mm]
 

Sq.m/L == 1/mm
Sq.m/L/mm == 1

Identities like this would save you a lot of unnecessary coding.

If you like to transform volume to weight, then add density field. Dencity would be non null for the materials where you'd like to calculate weight from volume, and null, otherwise.

> > > Some treatments require a pigment to be added. The calculation of this is
> > > dependent upon Qty of other materials, which again changes from product to
> > > product. Examples of this:
> > > Rate * (Total Qty of liquids [Primer + Resin + Sealers])
> > > Rate * (Total Qty of Sealers only)
> > > Rate * (Total Qty of Resin & Sealers [not Primer])
> >
> > Do you list pigment in the table of materials as well?
>
> Well, I'm not sure how that would be done. I'd say not, because of the fact that eg. the
> Rate must be multiplied by the sum total of the quantity of all sealers). In this case the
> PigQty is not dependant on Rate and Area, but Rate and Mat'lQty. So I'm thinking it would
> have to be stored in another table.
>
> > > Then somehow allow user to enter the rates in a form, and come up with some
> > > code to figure out which materials to sum.
> >
> > In a treatment form a user adds marerials and rates for it. In your
> > datamodel you have many-to-many relationship between Materials and
> > Treatments. So what is the problem?
>
> The fact that Pigment depends on other materials.
> Would you like to see a 56kb zip of the calcs I'm trying to transfer (small XL sheets)?

If you feel that you can extract 100 lines of the most important formulas, please post them to the newsgroup. I think a message with 56K enclosure can be posted to the newsgroup, as well. Otherwise, mail it to me. (As I mentioned before, there are obvious identities that can reduce your number of cases). Received on Mon May 20 2002 - 05:03:46 CEST