SQLServerCentral / Editorials / SQLServerCentral.com / I am not a Schema / Latest Posts

RE: I am not a Schema

L' Eomot Inversé — Sat, 27 Aug 2011 05:35:58 GMT

I guess schemas can be useful to structure data, but SMSS makes it hard to use them for that . Generally I don't want to build big databases, I want to build lots of small ones - put data which is essentially read-only in separate databases because it should have a different backup scheme from mutating data, which you can't do with schemas. Also, if thet essentially read-only data consists of several chunks with different lifetimes (one chunk gets replaced every 6 weeks; another every 8 weeks; another every 3 months) I want to split it into sepatrate DBs so that the DB is the unit of replacement (with sensible use of db renaming, replacement doesn't require any downtime; and smaller DBs mean less chance of someone wanting to access it during the small fraction of a second it takes to switch). And I don't want all my eggs in one backup basket even for the mutating data - because restores take too long (yes, I know I can buy tools to get around it; but I'd rather just buy an extra sever with a couple of Terabytes of storage to do a full restore onto, and then pull the bits I need across from that - probably cost me less than those tools by the time I account for the cost of people learning to use them).I do however want referential integrity constraints - so that will sometimes tend to push things together into one big DB; asking for cross-db referential integrity constraints would probably be laughed at, and anyway I think that if I have such a constraint I probably want both sides of it in the same backup. So providing an extra layer of structure could be one place where schemas would be really useful if only SSMS handled them sanely (but it doesn't: changing filters all the time is a pain, and when one wants to see two schemas at once they are not nicely separated). They are also useful for handling protection, I'd rather assign permissions to access a schema than to access individual objects in it - but the highlighted sections marked [b]Important[/b] and [b]Caution[/b] on [url=http://msdn.microsoft.com/en-us/library/ms187940.aspx][[i]the BoL page on GRANT Schema Permissions[/i][/url] suggest that using schemas that way is fraught with pitfalls.I think that considering all the above schemas are good, but they could easily have been better. Their treatment in SSMS suggests half-baked approach, and the pitfalls in the permissions area could perhaps have been avoided, or at least mitigated (the caveats referred to above show that someone in MS was thinking about the pitfalls - it's a pity they didn't think of a way to eliminate them, instead of just documenting them).

RE: I am not a Schema

jeffery.baynard — Sun, 24 Jul 2011 02:06:52 GMT

@LutzM: I'll try to find out. I don't know alot about what happened because the "acquiring company" tried to upgrade to 2008 R2 before our departments were integrated. Put it to you this way:The version of the "system of record" COTS product that the merged company has chosen to use (the latest) runs only on SQL Server 2008 R2. It's a very good product and pretty much pays Medicare claims with a 60-80% adjudication rate (getting rid of a dept of 100s of people) by running each claim through hundreds of rules and automating payment to providers. Lovely. Again, I have used this COTS for many years but for the "acquiring company" it is all new to them. I recommended to them a nightly backup/restore (using RedGate or some compression backup type) to get the online system image to the warehouse every night, as that's how we (the acquired company) have done it for several years with great results and about the same amount of volume. Sure it takes about 3 hours to backup the db, compress it, move it, and then restore it, but then you have it locally on your warehouse server so everything blazes and it's a simple, foolproof mechanism.But then we realized $hit, the "acquiring companies' " warehouse servers are still on SQL 2005 because of the failed upgrade because of that CTE performance problem. You can't restore a SQL 2008 R2 db onto a SQL 9 server duh (actually took me a couple days to realize this, sometimes I wonder if I'm just losing it lol).So I said, hey, we've got like until 2012 before the first deliverables are needed so surely that's enough time to get your warehouse boxes to SQL 2008 R2, right? I mean we can't have them stuck on 2005 forever right? Apparently, the "acquiring company" is so scared, or the "upgrade" that was attempted when I was not there went so poorly that they are yanking that option off the top of the pile and are now looking into my second suggestion: SQL replication (as apparently we can go backward from SQL 2008 R2 to SQL 2005, publish just the articles we need, and even change up the indices on the warehouse side to better suit crunching these tens of millions of rows).So "they" (and I hate to still use that term but for lack of a better term) are doing a POC of SQL replication) and if it is not provable by end of July guess what? We have to write dozens of SSIS packages to move the data from the online server to the warehouse server. I'm like, cmon how far down the rabbit hole do y'all wanna go? Eventually "they" have to upgrade these servers and then all this SSIS code would be throwaway.In other words they are TERRIFIED of upgrading, bottom line.I wish I knew more of what happened. There's a guy at work who's sort of a neutral third party who I'll try to get the skinny from but I know that for sure the issue with upgrading to 2008 R2 was with the CTEs and had to do with performance and fixing it with join hints.My interest is very piqued as well.... Give me a few days to see what happened during this past "upgrade."

RE: I am not a Schema

LutzM — Sun, 10 Jul 2011 04:02:51 GMT

@Jeffery:[quote]Microsoft's official solution: modify all code to use join hints (I'm guessing hash or merge)[/quote]Do you have any source available for that statement?

RE: I am not a Schema

jeffery.baynard — Sun, 10 Jul 2011 01:40:48 GMT

Wow, great question. First, before I give my input, a little background on myself might help:My background is primarily in SQL Server 2000+ data warehousing (both relational and "cube"/dimensional). About 12 years experience mostly as what I would call a "Senior level database programming." I have some experience in Oracle 8, 9i, 10i, and IBM DB2 UDB v6 and v8 from prior employers as well. Also with Informix, DB2 (mainframe), Pervasive, IDMS (loved that "non-SQL" hierarchical data model !!), VSAM, yadda yadda, etc. I believe that in Oracle, a "schema" is the highest container level, with a schema "containing" databases and users, while in SQL Server a schema is more like an "owner," the SQL instance itself containing the databases. Regardless, in both instances, [b]schemas are fundamentally nothing more than containers[/b].So for many years lately I worked in an environment where we (I, keep reading) created lots of databases for arranging and organizing stuff based on functional, business area. Worked great. On a single server we'd have daily, or log shipped "restored" images of operational systems as databases, databases that were nothing more than a set of views onto those "restored" images (as an abstraction layer), "staging" databases that would have staging tables and code related to that functional area and any ETL, a "utility" database that would contain code to copy tables, drop tables, routines for logging, enable/disable jobs, analyze tables, create indices based on a config table, move data from server to server via linked servers, etc., "reporting" databases that would contain reporting procs, etc., and finally "consumption" databases that users would hit directly that would contain either final denormalized "subject matter" based tables and/or "operational data store" based tables that was simply smaller data"marts" using several source systems as their input.I also was the senior DBA for this same company "lately" (a small, privately held company with more than 1 billion dollars as income and with 2 dbas lol, me and one other "mid level" lady). Now, we've been purchased (acquired) by a public company with the same basic size but lots more "red tape" lol.... compliance, policies, etc out the ying yang lol.Another note... about 2 years ago I moved laterally from DBA to "programmer III" doing mostly database programming for warehouses and lots of ETL/SSIS/dts conversion, etc.Anyway, let's cut to the chase... This new company has chosen to use our primary system (of record) as the company wide best practice, so I'm on a project to incorporate the data from this system into the existing datamart of the "acquiring" company. Good for me since I've worked with this data for several yeas, I'm in managed health care by the way (a Medicare Advantage provider).So this existing datamart uses MANY "schemas" (and CTEs but don't even get me started there). At first glance, the system looks deceptively simple. A staging db, a "build" db, and then a consumption DB which is just views into the "build" db. That's it. 3 dbs on each server (dev, uat, prod). It's the first time I've worked outside of "dbo" land.While I understand the reason for doing it this way, and I've since caught up on the improvements and reasons why one would build a datamart this way, my first reaction was simply, [b]why? I mean, 99% of us just stick to dbo and break thing out either with different dbs or by simply naming things well (a good name goes a LONG LONG way). My first gut reaction was simply of unneeded complexity.[/b] Sure there are some nice things you can do with schemas (esp permissions) but again, why? Properly diviided up databases give us nice separation of roles and therefore permissions required.The more I work with this, the more I realize the developers who wrote this corporate datamart were the kind of people that, when SQL Server 2005 came out, sat down with the "what's new in SQL Server 2005! document" and simply tried to use all the latest and greatest features for no particular reason except for experience and their resume. Take CTEs for example. They sound great right? But these folks used them for EVERYTHING. Personally, I think they are good for maybe a small subset of occasions but otherwise make code look MORE complicated than it needs to be, and, more importantly, goes against the grain of what 99% of current development looks like. So what happened? They tried to recently upgrade their warehouses to SQL 2008 (before the acquisition) and nothing would run because apparently performance stinks for CTEs in SQL 2008 (or 2008 R2), or there is some bug or difference with the way SQL 2008 (R2) generates query plans for CTEs, and remember we are talking about a datamart working with tens of millions of rows and tables that are dozens of gb of data. So here's another great example of why to NOT use the "latest and greatest." Microsoft's official solution: modify all code to use join hints (I'm guessing hash or merge) lol. We all know that join hints work great but are a LAST RESORT way to fix something !I know this has little to do with the topic at hand. But my point is, all things being about the same, I think it's always best to do things the way most everyone else does it. Schemas are a db concept that fall into this bucket. I find them intriguing and interesting but again they fall into this bucket of "why?" Just be consistent, don't be clever. Don't try to show off how "good you are" by doing things differently. Show how good you are with consistent deliverables and with code that can be easily maintained by any level of contractor your company might hire.We all love technology and we all love database engines (otherwise you wouldn't be reading this thread right now), but don't fall in love with things like schemas. Find some other technology to fall in love with :-)

RE: I am not a Schema

JasonRowland — Sun, 23 May 2010 21:30:57 GMT

I can see the reason for keeping databases segregated when you have a number of databases that each services an individual client and the databases are of high visibility to those clients. If something goes wrong with 1 database you only have 1 client calling, but if all the clients shared 1 database… Well, I wouldn’t want to be in that situation.

RE: I am not a Schema

Eric M Russell — Wed, 12 May 2010 13:22:40 GMT

[quote][b]shannonjk (5/12/2010)[/b][hr]...I was just curious if there was any sort of intuitive file/filegroup structure one should follow if designing a complex database schema system.[/quote]This MSDN article describes some of the design considerations regarding multple database files and a list of general recommendations. For example, would it be beneficial to perform seperate file group backups?[b]Using Files and Filegroups[/b][url]http://msdn.microsoft.com/en-us/library/ms187087.aspx[/url]One interesting experiment would be splitting a large primary key table and it's foreign key tables on seperate disks, or splitting indexes belonging to a large table into a file group on another disk.

RE: I am not a Schema

Brad Hale — Wed, 12 May 2010 13:17:35 GMT

My rule of thumb is to break it out as follows(minimum) as a starting pointDataIndexes for DataRead Only DataIndexes for Read Only Data"Read Only" can encompass seldom updated data as well. You can also go further and create files/groups for High IO data and indexes as well. If you have large tables that are commonly joined you can separate them also. You can also break up tables containing large amounts of varchar data into separate tables and put them into different files/groups as well.

RE: I am not a Schema

shannonjk — Wed, 12 May 2010 12:56:46 GMT

Yes I do that with the tempdb and logs already :-D.I was just curious if there was any sort of intuitive file/filegroup structure one should follow if designing a complex database schema system.

RE: I am not a Schema

Eric M Russell — Wed, 12 May 2010 12:50:39 GMT

[quote][b]shannonjk (5/12/2010)[/b][hr]How would you handle best practices as far as database file structure if you merged databases to one and used multiple Schemas? For instance if I put 2 databases together and split them into 2 schemas...would it be proficient to create 2 file groups and assign each 1 to each file group? Or at least 2 files within the same file group?[/quote]A general best practice is to put your tempdb and transaction logs on seperate drives from your user data files. You almost can't go wrong there, regardless of the application. However, I wouldn't consider splitting schemas into seperate file groups really a best practice, but rather a physical architecture decision depending on the data usage patterns of your specific application.

RE: I am not a Schema

shannonjk — Wed, 12 May 2010 12:33:32 GMT

How would you handle best practices as far as database file structure if you merged databases to one and used multiple Schemas? For instance if I put 2 databases together and split them into 2 schemas...would it be proficient to create 2 file groups and assign each 1 to each file group? Or at least 2 files within the same file group?

RE: I am not a Schema

Nathan Hunt — Tue, 11 May 2010 17:34:28 GMT

Using schemas in SQL 2005 definitely makes my job easier in developing the database used for our Portal system. Being able to logically separate objects using schemas to match the various applications I build for the Portal makes it easier to organise and keep track of. I think using the built-in DRI within a database is also more robust than trying to develop triggers for cross-database integrity, which will be error prone depending on the skill of the developer.With all considered, having schemas be more powerful and flexible just gives us all more choice over how we structure our databases, etc, which I think in this instance can only be a good thing!:-)

RE: I am not a Schema

Eric M Russell — Mon, 10 May 2010 10:31:04 GMT

[quote][b]eric_russell 13013 (5/10/2010)[/b][hr]I believe that referential integrity constraints are important in a database. If you have data models for two or three tightly integrated applications with overlapping foreign keys and sharing of reference tables (ex: Customer, Billing, Workflow, Inventory), it's great to now have the options of containing them all in the same database, creating all appropruiate constraints and backing them up as a total unit, while still keep the tables logically segregated using schemas.[/quote]I'm not sure I follow. I can grant execute permission on a stored procedure, containing a cross schema join, to a public user without granting select on the underlying tables.[code="sql"]use AdventureWorks;exec [dbo].[uspGetManagerEmployees] 3;go[/code][code="plain"]ManagerID ManagerFirstName ManagerLastName3 Roberto Tamburello158 Dylan Miller263 Ovidiu Cracium[/code][code="sql"]select top 1 * from [HumanResources].[Employee];select top 1 * from [Person].[Contact];go[/code][code="plain"]The SELECT permission was denied on the object 'Employee', database 'AdventureWorks', schema 'HumanResources'.The SELECT permission was denied on the object 'Contact', database 'AdventureWorks', schema 'Person'.[/code]

RE: I am not a Schema

Henry_Lee — Mon, 10 May 2010 10:24:55 GMT

[quote]If both schemas are owned by DBO then you get ownership chaining just like if all your SPROCs were in the same schema, but you can organize your tables into logical groups. [/quote]Hmmm...pretty poor on my part...I flat out missed this. Looks like I have some cleaning up to do this week. Thanks for the correction, Darren.

RE: I am not a Schema

Darren Wallace — Mon, 10 May 2010 10:01:30 GMT

[quote][b]Henry_Lee (5/10/2010)[/b][hr]I do not like different schemas within the same database, since they break the ownership chain. Joining different schemas in a proc forces me to grant permissions on the underlying objects rather than just on the proc.[/quote]Unless you're using SQL 2000 (where we really shouldn't be talking about using Schemas as they aren't fully implemented) I have to disagree with your assertion. When you use schemas for logical separation in SQL Server 2005+ you don't have to have different owners on the schemas. If both schemas are owned by DBO then you get ownership chaining just like if all your SPROCs were in the same schema, but you can organize your tables into logical groups. Personally I like to put all of my tables in a set of schemas and my SPROCs in a different schema (all owned by dbo). Then I just GRANT EXECUTE ON SCHEMA::MySchema and voila, no permissions chaining problems, execute permissions easily granted, and I don't have to worry about permissions leaking for all of the system SPROCs in DBO.-DW

RE: I am not a Schema

Henry_Lee — Mon, 10 May 2010 08:18:21 GMT

I do not like different schemas within the same database, since they break the ownership chain. Joining different schemas in a proc forces me to grant permssions on the underlying objects rather than just on the proc.

RE: I am not a Schema

Eric M Russell — Mon, 10 May 2010 06:52:27 GMT

I believe that referential integrity constraints are important in a database. If you have data models for two or three tightly integrated applications with overlapping foreign keys and sharing of reference tables (ex: Customer, Billing, Workflow, Inventory), it's great to now have the options of containing them all in the same database, creating all appropruiate constraints and backing them up as a total unit, while still keep the tables logically segregated using schemas.

RE: I am not a Schema

Chris Anderson-432071 — Sun, 09 May 2010 23:18:55 GMT

I've started adopting schemas, and have migrated a system that originally was designed with multiple databases to serve a single end data warehouse into schemas for two reasons:1. DRI across schemas - before schemas, i had the ugly option of a trigger, or would even sync multiple copies of the same data between databases within the same server to provide a base in each db to DRI against. If a deletion or update in one, or in a master set, conflicted, it would be discovered at sync time rather than at the time of the change itself. Generally, in an OLTP application avoided the architecture that requires DRI to cross schemas. In the OLAP-oriented solution, it has worked well to have a single schema containing measure metadata, to provide validation for user entries in another schema, and provide a base for star schema tables in another schema.2. Database objects and scripts can be written polymorphically - in a multi-tenant architecture, multiple databases required any views, sprocs, user-defined functions, or ad hoc scripts to reference the databases they touched (i.e. "SELECT * FROM {Customer}SourceData.dbo.RawData" with the {Customer} parameter having to precisely and manually be filled in...each... and...every... time a script was ran... and carefully too, to avoid accidental cross-polinations. With schemas, the SQL becomes "SELECT * FROM SourceData.RawData", and can be deployed across customer databases with no changes, and no risk of accidental cross-polination of data.

RE: I am not a Schema

ricva — Sun, 09 May 2010 19:58:17 GMT

I have been using schemas during the last 8 months and like the ability to "group" the objects. One spot I use it is with partitioned tables. I have a schema used for truncating data (call it trunc). You can switch a partition into this trunc schema (the two tables structures must be identical) and then TRUNCATE TABLE in the trunc schema. Very fast way to delete data on a very large table.

RE: I am not a Schema

Hugo Shebbeare — Sun, 09 May 2010 18:27:04 GMT

Great Topic, wrote on this last year (and should update it too): http://www.sqlservercentral.com/blogs/hugo/archive/2009/07/06/object-grouping-best-practices-using-schemas-for-logical-separation.aspxLove Oracle, and whenever I hear the argument that MSSQL is cheaper because it is easier to manage more databases...I can't help but scream you are comparing Apples and Oranges. Simply cannot compare the two, because Oracle prod installations use Schemas way, way, more than in SQL Server. In corporate environments this started changing a load last year, within the several groups I worked with. Thanks Phil, for pointing this great database organisational tool out in the newsletter.1506 Pauline-Julien Montreal, QC H2J 4E4 Mobile: (514) 812-5087 http://Intellabase.com hugo@intellabase.com SQL Server Most Valuable Professional 2010Simple-Talk.com Technical Authorhttp://www.simple-talk.com/author/hugo-shebbeare/SQL Server Central (weekly) Bloggerhttp://www.sqlservercentral.com/blogs/hugo/

RE: I am not a Schema

Steve Jones - SSC Editor — Sun, 09 May 2010 16:46:57 GMT

I haven't seen them used much, especially in third party products, but I always wished that back in 2000 we would have had them instead of the owner.I think they could provide some benefits, and I'd have to work with them more in some larger databases to see. The user of roles to me, has always worked well, and it's eliminated the need to qualify everything. I can see people getting confused with separate schemas, especially if they have different defaults. My thoughts in the past have been like Jeff's. Use separate databases if you need them, however I do know that there are better tools available now, like Hyperbac and SQL Prompt, to make development easier.

RE: I am not a Schema

Paul (scotchy) Scotchford — Sun, 09 May 2010 15:49:27 GMT

I use schemas all the time in datawarehouse db's I created, they are especially useful when dealing with smaller client Data Marts and I dont want to use a seperate db for staging , I just create a [b]staging.[/b] schema for all the ETL related work.To extend this further I use a [b]dimension.[/b] schema and a [b]measures.[/b] schema too , in order to keep order for the Data Mart objects.

RE: I am not a Schema

SQLNightOwl — Sun, 09 May 2010 11:59:04 GMT

I use schemas to make separate logical divisions within a database to partition off common functionality. I’ll also create a file group to hold data for some schemas. One I have is “ref” for common lookup values that are very stable (man of schema = ref file group = Reference). Another schema I have is “io” – guess what I do with that one?I also use schemas for security purposes (create role and assign roll access to objects based on schema). Schemas make it simple to have DRI between common objects (list of states, departments, employees, etc.) and application specific objects (accounts, loans, sales orders, etc.).I can easily see how to apply this in a datawarehouse (fact, dim, stage, load, rpt, etc.)When it comes to SSMS, I like the idea of having a flat view of all objects by type but having a schema organized listing would also be nice. How about a user option to permit a filter at the database level that cascades down thru all object types?@Jeff Moden – I don’t want to shill for a product but HyperBac (recently acquired by Red Gate) allows you to connect to backups via an ODBC driver so you can recover specific items from a backup. We use their product for backup encryption/compression and have used this feature several times. One of nice features is that the backup is smaller so you can avoid the T-Byte connection. I guess you can mark me down as a fan on this one.

RE: I am not a Schema

James Stover — Sat, 08 May 2010 20:30:05 GMT

I use an "Error" schema in my data mart. I re-direct error rows from the SSIS data flow to an identical table in the error schema. This makes sense to me because the domain of the data is the same and is used for the same application. However, I'm not a fan of mixing different data domains or different application data in the same database using different schemas. For example, I have seen "staging" and "prod" schemas live in the same DB. I typically wouldn't do this because the two serve different purposes with different recovery & support models. Of course, when you are being gouged and screwed for third-party, per-database support I can understand the desire to stuff everything into one database using different schemas.

RE: I am not a Schema

Jeff Moden — Sat, 08 May 2010 19:39:23 GMT

There are two reasons why I don't like and will avoid the use of schemas if at all possible...1. "All the eggs in one basket". More specifically, all the "restores" in one basket. If anything goes wrong and you don't have a separate tera-byte capable server to do a restore to get back one lousy schema or table when something goes wrong, the whole bloody company is OOC for the duration. I'd rather put up with the bit of headache that goes along with separate databases for separate functions and the creation of synonyms or pass through views where needed.2. It reminds me of Oracle... and even though I worked with it for 3 years, I hate Oracle. ;-)

RE: I am not a Schema

lancea — Sat, 08 May 2010 16:19:55 GMT

From my observations (my role is only "advice from a distance" for our larger developments), schema are simply not used. Business areas of the model are split into separate databases which results in a mess. Administrators, developers and users (those directly querying the databases) never have easy access to the big picture. I don't see this changing anytime soon because of the way large developments are run. Maybe if there was a "SQL Server architect", as opposed to generic architects who are invariably only slightly aware of any product-specific features. The people who are most aware of "features" such as schema sadly don't get much of a say in a big project.I still like separate databases for staging areas, where all or most of the tables are truncated between loads. The danger with schema becoming popular is that you'll get people deciding they are the answer to everything.

RE: I am not a Schema

Brad Hale — Sat, 08 May 2010 16:16:35 GMT

[quote][b]Phil Factor (5/8/2010)[/b][hr][quote]I was wish Management Studio behaved like LinqPad when it comes to the object explorer. Rather than DB->Tables, I'd prefer DB->Schemas->Tables[/quote]I agree. I find the object browser puzzling in the way it mixes objects from different schema. Where should the separation be? I'd expect that, when you click on the database, you should see a list of your schema. Each schema would contain tables, procedures etc, just as it does at the database level now.[/quote]Just use filters. Right click -> Filter -> Filter Settings

RE: I am not a Schema

Anil Das — Sat, 08 May 2010 16:12:19 GMT

I'm a big fan of schema, both to logically partition a database and to make it easy to assign appropriate permissions. Re: SSMS, I use the filter option all the time, and schema is one of the filter criteria. Re: extended properties, I use them a lot also. I commit all my view, procedure, function, etc. code to Perforce and populate extended propertiy statements in the script with RCS keywords. When I deploy, RCS keywords like $File$ and $Revision$ are then in the object definitions in the database making it easy to determine later what exactly was deployed.

RE: I am not a Schema

RobertYoung — Sat, 08 May 2010 16:01:01 GMT

Having spent most of the last decade mostly in DB2 (both mainframe and server), and lessly in SQL Server, I've come to take schemas for granted and get confused when they're not there. The question of total addressable data is less clear. I'm not sure that any of the schema supporting databases engines can hold as much data per schema as other databases do per database. So, while schemas allow for segregating tables by some factor, they don't necessarily allow for larger integrated databases.

RE: I am not a Schema

Phil Factor — Sat, 08 May 2010 15:21:35 GMT

[quote]I was wish Management Studio behaved like LinqPad when it comes to the object explorer. Rather than DB->Tables, I'd prefer DB->Schemas->Tables[/quote]I agree. I find the object browser puzzling in the way it mixes objects from different schema. Where should the separation be? I'd expect that, when you click on the database, you should see a list of your schema. Each schema would contain tables, procedures etc, just as it does at the database level now.

RE: I am not a Schema

Brad Hale — Sat, 08 May 2010 14:12:45 GMT

I use them a LOT. Especially for applications (SaaS, CRM's and so on) where I have a Global set of tables, etc... that all my end users need. That way I have all the global data, procs etc... in one place for doing upgrades and maintainance and can still isolate my users data.

RE: I am not a Schema

Michael DePouw — Sat, 08 May 2010 12:53:57 GMT

I think schemas are great. I use them to better organize a database.Our primary line of business db has around 300 tables and without schemas it would be a mess to find tables.I'm not a DB admin though, I'm an app developer.I was wish Management Studio behaved like LinqPad when it comes to the object explorer. Rather than DB->Tables, I'd prefer DB->Schemas->Tables.

I am not a Schema

Phil Factor — Sat, 08 May 2010 12:29:30 GMT

Comments posted to this topic are about the item [B]I am not a Schema[/B]