Whilst I cant say to have ever heard of the rule, static content has advantages that database servers are unable to provide as easily.
SATA drives usually have lower mean times to failure, are slower and perform less well at random I/O. The upshot is their cost per GB is cheaper.
When you store media such as static content, the system typically will cache the content so its not normally read much from disk, this negates the need to have a high speed disk so much.
This is especially true for websites where 90% of the data presented makes up 99% of the requests.
Databases on the other hand typically have an IO profile that is a lot more random. Databases also usually dont rely on the caching subsystem of the kernel to manage its content, so it can benefit to using faster disks. They also tend to perform many more writes than static content which is where the SAS drives can really help.
Bear in mind, there are so many shades of grey that its not as simple or as straight forward as that.
- Maybe your database is not used much?
- Perhaps you know exactly what tables will be read and the probability of the data being used?
- Maybe database writes are hardly ever done?
- Perhaps the response times your looking and concurrency numbers you have can be acheived effectively with SATA?
I wouldn't say there is a 'rule of thumb'. Instead, why not get some I/O measurements for your application now and what you anticipate your need might be in 2 years. Do you think that SATA will be suitable then? What about SAS, would that be? Maybe SSD is better still? If your talking 30ms faster retrieval times with SAS, is it really worth spending more? Do your customers demand that 30ms extra speed?
For most of the work I do, the numbers being generated by our operation dont really warrant SAS. And - anyway the margin of performance you get versus the cost-per-GB isn't that attractive for me. Now with SSD on the market I am even less impressed with SAS offerings.
That doesnt mean I am saying SAS is not right for you. But figure out your cost per GB, figure out what your performance needs are probably going to be now and in a few years then compare the results against what your clients specific needs would be.