March 19, 2011 at 10:43 am
hello...I have a table called Images which has images data , now...I want to create another table to hold date for image thumbnails , I have four thumbnail sizes so basically four types of thumbnails...I was thinking to create a thumbnails table , but this table is going to be large soon...so without thinking It would be later slow to have a query joining between two tables...so I was thinking to create another four tables for each thumbnail type , but that seems somehow miserable....so my final thought was to create two tables for the thumbnails , one for the smallest thumbnail and the other for the other sizes(which are less frequently used )....can someone tell me what is the best design for ths ???
March 20, 2011 at 8:44 am
Mazenx (3/19/2011)
hello...I have a table called Images which has images data , now...I want to create another table to hold date for image thumbnails , I have four thumbnail sizes so basically four types of thumbnails...I was thinking to create a thumbnails table , but this table is going to be large soon...so without thinking It would be later slow to have a query joining between two tables...so I was thinking to create another four tables for each thumbnail type , but that seems somehow miserable....so my final thought was to create two tables for the thumbnails , one for the smallest thumbnail and the other for the other sizes(which are less frequently used )....can someone tell me what is the best design for ths ???
Have you ever heard abount indexing?
_____________________________________
Pablo (Paul) Berzukov
Author of Understanding Database Administration available at Amazon and other bookstores.
Disclaimer: Advice is provided to the best of my knowledge but no implicit or explicit warranties are provided. Since the advisor explicitly encourages testing any and all suggestions on a test non-production environment advisor should not held liable or responsible for any actions taken based on the given advice.March 20, 2011 at 8:47 am
Yes , the table is already index with clustered and non-clusetered indices..I just want optimum design.
March 21, 2011 at 5:56 am
Whether the table is large or not, if you have the write indexes on it, you should be able to retrieve your data easily. You might want to consider partitioning for the table if it really is getting that large, but I wouldn't break the table up, especially if the basic retrieval mechanism has to be table to find the same data from multiple tables. That's going to add huge overhead to all your queries.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
March 21, 2011 at 5:59 am
Thanks , How can i mark your post as an answer?
March 21, 2011 at 6:38 am
It's not that kind of site.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
Viewing 6 posts - 1 through 6 (of 6 total)
You must be logged in to reply to this topic. Login to reply