Re: PHP, MySQL and snippets of info ...

"ManChild" <starritt@gmail.com> wrote in message
news:xy1Ye.79127$3S5.75439@tornado.rdc-kc.rr.com...
>
>> Exactly! I want to keep down the number of tables I have. I also want to
>> now keep my tables & rows to a minimum. I want to keep my Db to a
>> minimum. I also know that PHP takes a lot of effort.
>>
>> I like the idea of smoothing MySQL, I believe less columns, more data,
>> less calls.
>>
>> It's a toughy. But it has to be less effort on the server, the better.
>>
>> I reckon bad PHP is as bad as bad MySQL.
>>
>
> As an experienced DBA I can tell you that forgoing indexing (leading wild
> cards will force this) will have a significantly bigger performance hit in
> the long run than coding multiple short queries.

This is an interesting point. I have a database that people search by
retaurant name. I do a search "LIKE '*name*'". I know this isn't the best,
but quite a few businesses start with the word "The". e.g. I might search
for "Ritz", when I really want "The Ritz".

There's only 30k rows, but I want to build for expenetial growth.

>
> Even if you do not do the query with a join, querying on explicit numeric,
> indexed values will result in a miniscule query time for the applicable
> cards -- you can't thumb your noise at normalization and expect to get
> good results unless this is going to be a small database.
>
> Why does it have to be a choice between bad PHP and by database structure?
> Dont start off knowingly making bad choices :D Trust me - it never pays!

I just think one column into an array would be tidier in the schema and let
PHP do all the work. If I have multiple columns, it'll be just as much work
for PHP and more for MySQL.
Received on Tue Oct 18 02:26:23 2005