http://ayende.comAyende @ RahienCopyright (C) Ayende Rahien 2004 - 2021 (c) 202660First sentence should be "Database per application", i.e. perhaps a database for a business unit might include multiple apps and make more sense than trying to keep a separate one per app and not be able to use the nice features of a database such as foreign keys, etc. that start to cause hassles when you have to cross databases. http://ayende.com/3642/database-schemas#comment4http://ayende.com/3642/database-schemas#comment4Sat, 11 Oct 2008 12:20:20 GMTSchema per application only makes sense if your applications are very segregated. But if you are working on internal apps at a company you will have multiple aplications accessing the same data. Let's say you work at a finance company and you need to represent investments. You also need to represent trades which relate to investments and while there are separate apps that deal only with investments and some with investments and trades, those two things have a relation and are modeled as such in the database, foreign key's etc.. http://ayende.com/3642/database-schemas#comment3http://ayende.com/3642/database-schemas#comment3Sat, 11 Oct 2008 04:15:56 GMTTo throw my 2p worth... I was recently asked to set up schemas for workflow purposes. One schema was to be called Draft and another was called Live. The schemas effectively separated data in to those workflow stages. We had a sproc to mirror all data in pre-live over to live at the press of a "Publish" button. This was the domain of content management, so Draft was read/write and Live as read only to the app. It was neat, but I felt a little like it was going against the grain. My feeling is that using namespaces like this can get messy: changes to workflow invite more schemas! DRY is violated. Plus every db migration has to be applied across all schemas. And you need to apply tests to all "mirrors" of the schema. Think I'd prefer to keep schemas reserved for simple namespace as you suggest. http://ayende.com/3642/database-schemas#comment2http://ayende.com/3642/database-schemas#comment2Fri, 10 Oct 2008 19:32:23 GMTWow... 0 comments. Totally expected a flamewar on this one. Anyhow, totally agree. I'm sure someone will come up with a few technical reasons why schemas help with this or that, but by and large, I think you're right, Ayende. http://ayende.com/3642/database-schemas#comment1http://ayende.com/3642/database-schemas#comment1Fri, 10 Oct 2008 14:07:27 GMT