Wednesday, November 15, 2017
Monday, September 18, 2017
Monday, June 19, 2017
Friday, February 24, 2017
Wednesday, February 15, 2017
Monday, January 30, 2017
Ran across a great overview of when to use databases vs schemas to separate things.
Also, "separate schemas" or "separate databases" are 2 different concepts. Data that needs to be transactionally and referentially consistent needs to be in the same database. See One Database or Ten? blog article for more.Bonus link to this fine article
The most important idea about the log is this: the only way to get a transactionally consistent set of data over time is to have either just one stream of journal (log records) for the data, or to have multiple streams of journal that are robustly tied together, lock step. Because each database in SQL Server has its own, independent log file, the first situation is simple to implement – just use one database – while the second is very, very difficult. Splitting data into more than one database implies multiple log files, which in turn implies an independent log sequence. Having separate transaction log sequences means that, while it’s initially possible to perform a transaction across the two databases consistently and correctly, there’s very little guarantee after that transaction, in the space of backup and restore or disaster recovery, especially out in the real world.So if you want transactions to work, everything needs to live in one database. Easy as pie.