Ask them to prove that joins will "seriously" degrade the performance, and
quantify the level of degredation. If they don't, or can't, then Normalize
anyway, hang the consequences, and whip their heels to Putney Bridge....

Bill them for the extra "unneccessary" disk space their insisted upon
de-normalization incurrs.

Suggest that they stick an index on their views.

Hang the developers one by one until they stop whining about degradation of
performance vs normalization.

To have 300+ columns or attributes on a table, or entity, is rank stupidity
in my opinion, and I say this as both a DBA and a Developer!!

Oh, and if they need a reason, tell 'em You're the DBA, it's your Database,
and they'll do as you tell them so to do, by Divine Right!

Hope that helps... probably not... but... you have my sympathies...

Jeremy Greaves
Fenris Software Consulting, Inc


>From: "Chris" <mssqldba-ezmlmshield-x30855087.[Email address protected]
>To: "LazyDBA Discussion" <[Email address protected]
>Subject: Varchars & table width
>Date: Mon, 30 Apr 2007 17:34:43 +0100
>
>Hi,
>
>I have a couple of questions
>
>If SQL2005 will only use as much of a varchar as necessary, should you ask
>developers to limit the size of a varchar if they will definitely not use
>more than 8k.
>
>On the same subject. If a the maximum width is more than 8k, but only 1/3
>of the columns in each row will be populated at one time in the table,
>should you insist for the table to be broken down from 300+ columns into a
>more logical design. My developers are claiming this will lead to slower
>query times as they currently have views spanning 2 300+ column tables and
>claim more joins to smaller tables will serious degrade performance.
>
>can anyone suggest reasons why i should insist upon these tables being
>normalised. files will be uploaded to these tables on an adhoc basis
>through the day and then uses will only select from these tables.
>
>
>
>Core – DBA
>Threadneedle Investments
>DDI:      +44 (0)207 464 5446
>Email:   chris.wood-[Email address protected]
>
>CONFIDENTIALITY: The information in this e-mail and any attachment is
>confidential.
>It is intended only for the named recipient(s). If you are not a named
>recipient, please notify the sender immediately and do not read, use, copy
>or disseminate this information.
>
>CONDITIONS: Any offer contained within this communication is subject to
>contract and formal approval by the legal entity giving the offer.
>
>Threadneedle Asset Management Limited (Entered on the FSA Register - FSA
>Number 122194), Threadneedle Investment Services Limited (FSA Number
>190437), Threadneedle Pensions Limited (FSA Number 110337), Threadneedle
>Portfolio Services Limited (FSA Number 119174),Threadneedle International
>Limited (FSA Number 143014), Threadneedle Unit Trust Manager Limited (FSA
>Number119219) and Threadneedle Navigator ISA Manager Limited (FSA Number
>188889). Authorised and regulated by the Financial Services Authority -
>www.fsa.gov.uk/register/. Registered Address: 60 St Mary Axe, London EC3A
>8JQ.
>
>
>
>---------------------------------------------------------------------
>TO REPLY TO EVERYBODY , PLEASE CLICK REPLY-ALL, NOT JUST REPLY
>To post a dba job: http://jobs.lazydba.com
>To subscribe : http://www.LazyDBA.com
>To unsubscribe: http://www.lazydba.com/unsubscribe.html
>



MS Sql Server LazyDBA home page