Sean Redmond (1/30/2015)
What irks me is that there seems to be race to use eveyrthing that can be used up as soon as possible.Much to my chagrin, the developers are the ones chosen to develop the database (and not the DBAs). I am mantra-like in my telling the developers to use as small a datatype as possible. And that one customised index per stored procedure will make the DB slower not faster — especially once 200 SPs have been coded. They don't seem realise — or care — that when one third of a table size is data and two-thirds are indexes, that every write takes 3 times longer than without the indexes.
Especially among the developers, there seems to be a belief that everyone will follow them. If the code that they write is slow, then it is up to the sysadmins to get new, faster hardware. If the DB is running slowly, well then, let the DBAs sort it out. They like that sort of thing.
I want the DB that I manage to be as small as it can be— so no using NVARCHAR when VARCHAR will do nicely, no using DATETIME when only a DATE is needed and so on. I want it to be lean. I want to have as much necessary information on one fill-factor'd page as there can be. I don't want an obese database that hobbles along.
Not all us developers are like that but too many are. The NVARCHAR/VARCHAR decision can be tricky if one has heard that the system might need to handle internationalisation, however, using DATETIME when only a DATE is required is not only wasteful but error prone and usually due to developers not keeping up with database features1.
1Playing devil's advocate: it is difficult when you have your language, say C#, .NET Base Class Library, XML (and related standards XSLT etc.), T-SQL, JavaScript, Node.js (and the million other JavaScript frameworks). Types are a basic though and guidance from subject matter experts (DBAs, for example) should, at the very least, be considered.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!