I hear a lot about things that, it is a lot cheaper to buy new harddisk than pay staff to come up with genius ideas how to save resources. But what I don't understand, is how these databases handle a situation when I need to allocate a new harddisk. Should I design this in the application layer or leave these things entire to the database. And is it even possible to have multiple database files for one table on multiple drives and have them connected somehow?
- Anybody can ask a question
- Anybody can answer
- The best answers are voted up and rise to the top
migration rejected from stackoverflow.com Oct 8 '13 at 22:47
This question came from our site for professional and enthusiast programmers. Votes, comments, and answers are locked due to the question being closed here, but it may be eligible for editing and reopening on the site where it originated.
closed as too broad by a_horse_with_no_name, Mark Storey-Smith, RolandoMySQLDBA, Phil, Max Vernon Oct 8 '13 at 22:47
There are either too many possible answers, or good answers would be too long for this format. Please add details to narrow the answer set or to isolate an issue that can be answered in a few paragraphs.If this question can be reworded to fit the rules in the help center, please edit the question.
Leave these things entirely to the DBMS.
Most if not all DBMSes these days come with, or can be configured to work with monitoring software such that the DBA can be paged at 3AM should diskspace become a problem.
Of course, most DBAs would be rather more pro-active in monitoring something as basic as storage requirements to avoid being woken at such a time.
In general, when using a DBMS, you want to leave the headaches of monitoring and error conditions to the DMBS and its monitoring software. But be sure to talk with your devops team if you're building an enterprise class mission critical app.