|
|
Posted by elyob on 09/21/05 13:12
"Gordon Burditt" <gordonb.g6ok5@burditt.org> wrote in message
news:11j1dj24k5nbn37@corp.supernews.com...
> Incidentally, what ARE Bc and Ca? Bank debit card and cash?
> Bank of British Columbia and State of California Food Stamp cards?
>
These will be internal codes that mean something to me and will be
documented.
I was thinking Barclaycard, Visa, American Express, Cash, but haven't
actually got that far yet.
> Um, *WHAT TYPE OF* overhead? Are you concerned about disk space here?
Not disk space, but creating multiple rows will require more work from the
server. Personally I like the idea of keeping similar stuff in a single row
in the same master table rather than create multiple rows in a seperate
table. I'm looking at this as a technique for other stuff too, e.g. hotel
facilities.
One of my data suppliers for hotels has over 100 columns in one of their
feeds supplting details such as "internet 0", "minibar 1", "satellite tv 1"
.... personally one column aggregating all this stuff would be ideal. Maybe
overly complex at first, but saves a lot of extra work when populating and
reading that table.
So, rather than expand my table with 6 extra columns, I just add one column
with called "payment_type".
> (3) Minimum disk I/O used in updating the database
> (5) Minimum disk I/O used in querying the database
> (7) Minimum number of database rows
> (8) Minimum number of database columns
> (9) Minimum coding time for MySQL queries
> (13) Minimum (3) plus (5) (You have to state an assumed ratio of
> updates to queries).
> You may choose only one primary optimization. If you want more
> than one, chances are I can name an optimization that will improve
> one at the expense of the other. For example, for choices (2),
> (3), (4), and (9), don't use any indexes (a generally stupid choice
> if the tables are large enough to worry about disk space filling a
> floppy). For (1), you can, I think, put everything in one table,
> by adding a column for the table name, and include columns in that
> table for every column in the tables you're replacing. This is
> also a horrible choice by most normal criteria.
It's less about optimisation and more about tidy, concise tables. I just
don't feel right about creating either 100 columns for every snippet .. e.g.
for restaurants "kids menu", "vegetarian menu", "vegan menu", blah blah blah
....
> If you are doing SEARCHES by LIKE '%Am%' or LIKE '%Ca%', they'll
> still work. If you split the field apart by length into an array
> and look for appropriate array elements, PHP will like it fine,
> regardless of order.
>
I think I'd best test it out next and see how horrible a technique it is!
Navigation:
[Reply to this message]
|