Firstly, Databases are designed(via Schemas) before they are implemented. Would you really want to use a single database for this? You probably could, If you want.īut the best case scenario is multiple databases. and all these packages belong to one complex System. Imagine a system comprised of Inventory, Accounting, Engineering processes (E.g. One could argue that an approach is chosen to serve a need/requirement. Like any other approach in Software, each one comes with its own Pros and Cons. Of course, it's more complex than this, but the basics do apply. This way if any one machine experiences a failure, you lose no data, and at worst you'll have to restart a query. If you're going to use multiple machine for reliability and enhanced performance, perhaps you can structure them so that you have a master server with multiple warm/hot standby machines which could also be used to distribute queries across. the hardware which is used to serve the data.īreaking the database across multiple machines does you no good for the many reasons explained by the other answers in this topic. I think it's important to split the notion of "the database" into two pieces: the schema and data vs. What is the likelihood that a hardware failure is going to impact your application? If there is a 0.1% chance that any particular server may die on a particular day, are your chances better or worse that you're going to be impacted by a hardware failure when increasing the number of machines you're dependent upon? Thought experiment: Instead of dividing your database into seven pieces, split it instead into 7,000 pieces.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |