Why abbreviate schema names?

I've never seen anywhere using three-letter schema names but your comments are right, I can't think of any justification for naming schemas like that either. We do use schemas and they are a great feature, but I have seen some instances where developers have started to treat the schema name as part of the object name, e.g. "Policy.Details" instead of "Policy.PolicyDetails" - this often leads to multiple tables with the same name on different schemas, e.g. "Contract.Details" and "Policy.Details"  - then someone refers to the "Details" table.... I think this can lead to unnecessary confusion.

I agree with Nathan, I don't see anything as obtuse as the example you cite, but as a counter-point I do agree that typing longer schemas can be annoying in many-table queries (one of the reasons I like dbo).  I am using schemas but I generally turn off IntelliSense as it seems to get in my way more often than it helps.  Every couple of months I give it another spin (both the built-in and the Red-Gate version) but I always tend to turn it off quickly.

Likely SQL developers do it for the same reason they obfuscate table name aliases. With intellesence typing is not an issue.

All abbreviation in Column / Table / Filed names drives me nuts. There's no need for it, especially now intellisense is here to save your fingers. Why call a table ClmRecGrsAmt when you can call it ClaimRecievedGrossAmount, something that may actually make sense?

Our data modeling team are all former Mainframe COBOL folks and the naming standard for tables was 18 characters when I started.  After petitioning the Standards Committee, yes we have one, we were able to have the length of table names increased to 32 characters---ostensibly to make things more readable.  Now instead of SR_M_ADV_IVC_HST_S we get things like SHRCLASMSLSLD_PRTFFDSHRCLAS_VM

Hello from the C# world - abbreviations and prefixes/Hungarian notation where long ago deemed a code smell.  Intellisence does much to negate the need, but the bottom line is about readability, maintainability and lots of other stuff that ends in ability.

If you're basing architectural decisions on the "how quickly I can type a name" - you need to step back and ask yourself some questions.

David's hit the nail on the head there: naming conventions should be driven by clarity rather then brevity.

Code should aim to be self-documenting as much as possible, which isn't going to happen if object names are unnecessarily abbreviated.

Abbreviations in schema, table and column names drive me crazy.  Then again, so do aliases where you aren't referencing the same table multiple times.  Spell it out so that there is no ambiguity for the next person that comes along.  I don't need to search through the code to find out which table T39 belongs to... And I don't need to wonder what the Act schema should be used for (Actuarial? Accounting?).

We have both - some abbreviations work cause they are so well known, when their is any ambiguity, we move towards a short word that makes sense.  I don't see the need for automatedpaymentsystem.outstandingcollections when AP will do.  

but as you mentioned, right/wrong does not apply.  too short and its obscure, too long and its cumbersome.

Two reasons

1. Some database products has limit of chars in name

2. Once your product support multiple databases, you must use the most restricted one

Cheers

Much ado about nothing. Move on.

Much ado about nothing.

Defintely a balance.  Generally I err on the side of spelling out reasonably descriptive names for table and column names, but do abbreviate schemas names.  I think it's one of those things thats so pervasive in a particular app domain, that to constantly see it spelled out is counter-productive.  Think the people who use 'tbl*' as a naming convention for tables.  After about the third query you write, you're thinking "Yes, I know it's a table...".  Given an hour or so orientation to a database, I would expect most db professionals to quickly acclimate a few abbreviated objects (e.g. that the 'rec' schema refers to 'reconciliation', or 'recreation', or 'recordsales', etc. whatever it means to that database)