[thelist] CF: Request for Opinion

.jeff jeff at members.evolt.org
Sun Sep 8 15:14:01 CDT 2002


rudy,

><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> From: rudy
>
> > (or a table with a single record, ugh).
>
> was that teensie-weensie troll aimed at me?  okay, i'll
> bite
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><

that was most definitely not intended as a troll or flame bait.

><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> the ooak ("one of a kind") table concept has its
> advantages
>
> for one thing, it makes the app portable
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><

that's arguable.  if chosen wisely, the disk storage method can be just as portable and still allow you to maintain all the advantages of not hitting the database for what is most likely completely static data.

><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> given that you do want an admin screen for these odds
> and sods pieces of app data, it means you don't have to
> re-invent the esoteric code that stores and manages this
> data in some external file, which surely will vary from
> one scripting language to another -- just manage it like
> other database data using sql calls, which is a pretty
> standard coding technique that even junior coders should
> be comfortable with
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><

i don't believe it's my responsibility to code apps so they can be worked on comfortably by junior coders.  that's not what the client is paying me for.  the client is paying me to develop technology that will solve their business problems.  if that solution requires a complex collection of code, then that's what they'll get.  it might be nearly impossible for a junior coder to stumble their way through it and understand, but that's not the point.  readability of the code does not keep the client's business going -- performance of the code does.

now, i mentioned that if the disk storage method is chosen wisely, then the interface for the admin should be trivially different from storing the data in the database.  use the same mechanism as the frontend to get the stored data into memory -- cfinclude.  param the data to the appropriate form fields.  code the html-based ui.  write whatever data validation you need.  in your data processing template, instead of making a database call to store the saved data, simply write the data back out to the file in the same location it was before.  it really is no more difficult than using an ooak table.

><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> next, and this is perhaps a "killer" advantage, consider
> how the data might be used in the app
>
> one example is exchange rate
>
> in pulling out rows from, say, a product table, to
> convert the prices to the user's currency, you simply
> join the ooak table into the query and perform the
> calculation in sql
>
>    select product.description
>         , product.price * exchange_rate
>      from products, ooak
>        where product.pk in
>          ( select cart.product_fk
>              from cart
>             where cart.userid=  n )
>
> note how this is a cross join, with no join conditions
>
> that means every selected product row is joined with
> all the rows of the ooak table -- all one of them!
>
> no post-processing in your script to loop over records
> to perform the calculation
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><

data is data though.  it doesn't matter where it's stored.  i can do the same thing above, but without the join.

SELECT product.description
     , product.price * #Val(app.company.exchange_rate)#
  FROM products
 WHERE product.pk IN (SELECT cart.product_fk
                        FROM cart
                       WHERE cart.userid = n)

like your example, no post-query looping.  the best advice in the snip above would be to "consider how the data might be used in the app".  if thought is put into that, then the developer will most likely select the best method of storage for that situation which won't always be the database.

just my 2¢,

.jeff

http://evolt.org/
jeff at members.evolt.org
http://members.evolt.org/jeff/




More information about the thelist mailing list