Design a tempTable in class to hold a "matrix" of values

In another post I got to, by the great help of Martin, a solution with a TempTable to hold values.

In post you can see the discussion

So I want to create a class of a TempTable and then GetSettermethods to get and set the values in the table.

If I'm not wrong I can do that by (assume I created a class of type TempTable named "Commodity" 

public real parmOpen(int _id, real _open = 0)

//update value

if(_open != 0)


select forupdate Commodity where == _id; = _open;



return commodity::find(_id).open;


Wrote it form the top of my head, but its about the concept.

What do you think?

Parents Reply
  • I think that I demonstrated that that my code handling all 28 cases it's simpler than your parm method

    Nw when I read your code I understand. That is, what's coming in from oneventTickPrice.

    There are only 3 values from that method.

    The other fields, like spread, status, price 5 min ago, price 10 min ago, triggerprice, stopprice etc etc just to name a few, which are all calculated by me, has to be written too.

    Should that mean that everywhere I want to write an own calculated value, I have to call select forupdate temptable etc?

    But also everywhere I want to read a value, I have to write a select statement?

    That would make the code harder to read, that's why I have put it in the "parmMethods" (however I understand that that code was not designed for tables....)

    But I mean in my method PriceCalculation:

    tmpTable.Spread(_id, tmpTable.ask(_id) -

    Is easier to read than doing this with 3 selects in the code?

    So thats why I put those methods "on a higher level"

    Besides that all the other 25 selfcalculated fields has only to do with 1 id and independent of the tickType.

    And specially that I don't understand why I would spread it over more records per _id.

    If "I'm used to save data per _id" means that you're not familiar of primary keys consisting of more than one field, you've just learn something new. :-)


    I did mean that per id a record is hold, like custtable etc. I know primary keys of n fields.

    Now the above looks like I think I know it better than you Martin. Well...for sure that's not the case. Compared to you I'm a starter

    For sure it's good to code as clean as possible to avoid bugs etc, but it looks like we have a different view of the tabledesign in this case. I'm cracking my head around it:

    Is it that you think of more tables?

    1 with "basic data" and a lot of (myself calculated) fields , and 1 joined with this maintable, where you put the price records per _id and _ticktype as in your example?