To estimate the size of a database, estimate the size of each table individually and then add the values obtained. The size of a table depends on whether the table has indexes and, if they do, what type of indexes. It involves various calculations
For tables it is the sum of size of clustered index + the sum of the size of all the non clustered index
for heap it is page size i.e, 8192 * Number of pages that required to store all the rows
To know more, see [Capacity Planning], article from Microsoft: http://msdn.microsoft.com/en-us/library/ms187445.aspx
Database management systems must constantly face the trade-off of "speed vs. space," and generally speaking they tilt in favor of speed.
Also, if the database is anticipated to be large enough that per-estimation of space requirements is likely to be a factor, many other issues can pop into reasonable consideration. You probably need to have a RAID array. You probably should distribute parts of the database to different drives and volumes. Once again you are paying, with space and drives, for ... speed, redundancy, and so on. Thus, the more "important" an advance space-estimate is perceived to be, the less likely it is to be accurate.
And if you want to know the future growth rate of your database you should try Lepide SQL Storage Manager which having capability to forecast your database future disk space growth rate and manage the capacity of database via performing many operation like defragmentation, Partition, rebuild & reorganize the indexes etc
answered Mar 22 '13 at 12:59 PM