ilikawa (1/15/2016)
bSean Lange (1/15/2016)
ilikawa (1/14/2016)
@Sean Lange, what else do you recommend?On what topic? Seems that Bill provided a solid way to go about analyzing potential storage needs.
It's just that to me,this approach sounds to easy and simple to make.
In a brief summary, all what I would need to do is obtain each size of the tables on my database and divide by number of months in use. It's that all?
Well that would be accurate for historical storage purposes right? The total amount of actual used storage divided by the length of time in use. That would be very accurate description of how much storage was needed per month over the life of the system.
For new databases where no prior information has been stored in tables, how could I make the calculation to assign the storage?
There is no formula here. What does the system do? How much data do you anticipate being in the system. How much wiggle room is in the estimate? What are the storage values for each row? There just isn't a way to state you can calculate this by xxx. It comes down to the amount of storage needed per row and the number of rows. That varies immensely based on the datatypes, architecture of the tables, type of system, amount of users, amount of usage etc....
_______________________________________________________________
Need help? Help us help you.
Read the article at http://www.sqlservercentral.com/articles/Best+Practices/61537/ for best practices on asking questions.
Need to split a string? Try Jeff Modens splitter http://www.sqlservercentral.com/articles/Tally+Table/72993/.
Cross Tabs and Pivots, Part 1 – Converting Rows to Columns - http://www.sqlservercentral.com/articles/T-SQL/63681/
Cross Tabs and Pivots, Part 2 - Dynamic Cross Tabs - http://www.sqlservercentral.com/articles/Crosstab/65048/
Understanding and Using APPLY (Part 1) - http://www.sqlservercentral.com/articles/APPLY/69953/
Understanding and Using APPLY (Part 2) - http://www.sqlservercentral.com/articles/APPLY/69954/