I may have to re-think this.
That does make a lot of sense. We are not using those stats now ..... but maybe in the future.
Thanks for the help onion2k and everyone.
I may have a busy weekend ahead
BTW ... this wasn't for any commercial purpose or anything ....... just a friend of mine running a small pool.
nathanr wrote:MrPotatoes, can't you normalise and give them the tables they require as views instead? totally of topic but just wanted to throw that in!
i meant to reply to this lol
we have a part of the application that dynamically creates tables and pages. normalizing that is just unessessary. hell, ti's even in it's own database.
in another table that we have it's got 295 columns. it's a temporary table that holds some data before we take it out and manipulate it. to normalize that is really just unessessary. trust me, that table is as good as it's going to get. other tables we will be doing a full over haul on the database (and code thank god)
WorldCom wrote:That's why I wondered if the 90 columns was a huge overhead, rather than querying the 2 tables for the same stats. As soon as that information is in the table(or tables), it's just read back (one array) and displayed.
It's better to have a lot of rows than a lot of columns.
WorldCom wrote:That's why I wondered if the 90 columns was a huge overhead, rather than querying the 2 tables for the same stats. As soon as that information is in the table(or tables), it's just read back (one array) and displayed.
It's better to have a lot of rows than a lot of columns.
I do agree super ...... I should have thought this out a bit better. It was suppose to be a small project ... yea like that ever happens.
I may re-write it for next year but it's too close to pre-season to do it now. (gee I'm talking like I know football ... which I don't)
BTW, I got the stats I needed without an extra table
Thanks again for everybody's help. It definately points me in the right direction for future projects.