[PHP-DB] enum and bad planning

2002-10-01 Thread Jeffrey_N_Dyke
I have five enum fields, all Y/N. There is now(last minute) a requirment to report on all clients that said Y to more then one of the questions(its a survey). Had i known about this requirement, i could have made them BIT and had a simple 1/0 option and summed the fields to check the total

RE: [PHP-DB] enum and bad planning

2002-10-01 Thread John W. Holmes
I have five enum fields, all Y/N. There is now(last minute) a requirment to report on all clients that said Y to more then one of the questions(its a survey). Had i known about this requirement, i could have made them BIT and had a simple 1/0 option and summed the fields to check the

RE: [PHP-DB] enum and bad planning

2002-10-01 Thread Jeffrey_N_Dyke
: Subject: RE: [PHP-DB] enum and bad planning 10/01/2002 03:19

RE: [PHP-DB] enum and bad planning

2002-10-01 Thread John W. Holmes
PROTECTED] Subject: RE: [PHP-DB] enum and bad planning Thanks for the responses. I got one earlier that did the trick. I wanted to try as hard as i could from altering the table, as i was already using the Y value in other reports...and here is a great solution. this may help someone else. so

RE: [PHP-DB] enum and bad planning

2002-10-01 Thread Rick Widmer
At 03:35 PM 10/1/02 -0400, John W. Holmes wrote: You should BENCHMARK the two solutions and see which is faster. Or use EXPLAIN to see if there is any difference. I have no doubt this will be slower. Oh well, he wanted to keep the table definitions. Don't forget to consider the time required

RE: [PHP-DB] enum and bad planning

2002-10-01 Thread John W. Holmes
At 03:35 PM 10/1/02 -0400, John W. Holmes wrote: You should BENCHMARK the two solutions and see which is faster. Or use EXPLAIN to see if there is any difference. I have no doubt this will be slower. Oh well, he wanted to keep the table definitions. Don't forget to consider the time