I'd use one DB... but multiple owners.... So maybe the core items belong to the CORE owner, and the plugin ones belong to the default dbo
We use this concept in the app I'm working on. Wee have a REPO owner (called schema in Oracle) so the main tables belong to that owner. Then there's another DRAFT where we copy items from REPO to while they are worked. This keeps REPO clean while the service that accesses it can still use it, and if anything breaks, it happens in DRAFT. Once it's complete in DRAFT, it then goes through a workflow that pushes the changeset back over to REPO.
Something similar could be done in your case. By having different owners, you can segregate the tables and control how they are interacted with. It would also limit visibility using the SQL Server Explorer. And since it's all in one database, transactions are a breeze. The big change would be in how you access tables... instead of
You would doCode:SELECT * FROM someTable
There someTable is in the core owner, while anotherTable is dbo.Code:SELECT * from core.someTable st inner join anotherTable aTbl on st.id = aTbl.Fkey
-tg
(disclaimer - I think I have tht right, it's been a while since I've done this with SQL Server)




Reply With Quote