Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
Two scenarios:
Large application – One database w/all tables
or
Large application – Multiple databases w/relevant tables
Can anyone list the advantages/disadvantages?
Unless you have very specific reasons, keep everything in one single database. I cannot think of a single advantage of splinting one single schema into multiple DBs.
One single database creates one single unit of recovery, which allows for a consistent backup. It also presents one single unit of failover for high availability. With multiple databases one cannot take a consistent backup unless it freezes activity (often impossible). also multiple databases pose challenges in orchestrating a ‘group’ failover in case of failure (some DBs may failover to a new server, while other may stay behind).
Multiple databases offer advantages in multi-tenant models where each tenant can have its own database, specially if tenants may choose or opt-in on version upgrades (this is impossible with single DB). But this is a scenario with many databases having the same schema (same tables in every database), not splitting a schema across several DBs.
Scale out by data partitioning (sharding) can only be achieved by having multiple databases, but that is a different topic from splitting a database into ‘parts’ (each DB with a different schema). Shards have identical schema, but contain data for specific ranges.