May 7, 2003 at 7:37 am
I have a set of tables in which I will need to search on 5 to thirty of the fields. We have very few updates during the time the searches would be performed.
Assuming proper indexing on both, is better to have individual tables containing items to be searched within the PK and joining them as needed or creating a flat table with everything all in one.
May 8, 2003 at 12:31 am
check Denormalisation on the web. There a whole set of info needed to take that decision
Johan
Learn to play, play to learn !
Dont drive faster than your guardian angel can fly ...
but keeping both feet on the ground wont get you anywhere :w00t:
- How to post Performance Problems
- How to post data/code to get the best help[/url]
- How to prevent a sore throat after hours of presenting ppt
press F1 for solution, press shift+F1 for urgent solution 😀
Need a bit of Powershell? How about this
Who am I ? Sometimes this is me but most of the time this is me
May 11, 2003 at 1:33 pm
Hi,
I have a similar experience with one to one tables. First I designed several tables and now I have compacted them to one for the following reasons:
1. Multiple joins hinder performance.
2. You must maintain all the tables then inserting a record or inner join can eliminate a record from the result set.
3. You must store PK duplicate index multiple times.
4. If you add a new field you have to choose a table. You also have a bad possibility to add the field of the same name to two or more tables.
5. You cannot create view as select * if you use the same column(s) name for PK.
I have a couple of tables with fifty or more fields that perform quite vell. My advice is: one flat table.
May 11, 2003 at 6:25 pm
I always start normalized, then if I find a problem I can't solve using that structure I look at alternatives. In the scenario you describe, an indexed view might be a good alternative.
Andy
Viewing 4 posts - 1 through 3 (of 3 total)
You must be logged in to reply to this topic. Login to reply