Thank this author by sharing:
By Steve Jones,
The notion of a schema has been a part of relational databases for a long time. SQL Server implements this as the owner of the object. But is this a good idea? Have you ever questioned this?
I'm not sure it is. Our own Andy Warren wrote about Objects not owned by DBO, something which is only possible because of the schema. To me, having a schema is a place where one can easily get into trouble. Easily confuse themselves and others when there are two "employee" tables. When a DBA sees a different result than someone else because the schema's are different. When rights and permissions become overly complex because of the possible permutations.
Now I know that this separation can be good. We can each have own own "orders" table in the same database, security is tighter, etc. But isn't the idea of the shared database, out there on a server, in a climate controlled environment, managed by professionals, there so we can SHARE data. Don't we want the data accessible by everyone with access? Shouldn't we control the permissions and ensure their accuracy using the KISS principle rather than the kitchen sink method.
I like to keep things simple. Use the minimum needed and apply it as a standard. While I can't claim to have worked on the GM payroll database or designed the database Boeing uses to build airplanes, I suspect that there would not be a substantial reduction in the performance or usability of their databases if the schema were removed.
Agree? Let me know, it's not likely to get removed, but Microsoft will see what we think. Disagree? give me a reason, hammer me, tell me why the schema hasn't outlived it's usefulness.
©dkRanch.net May 2003
Return to Steve Jones Home
Schema versus Database
sync database design, database schema
We need schema binding across databases for a view to implement clustered index