Please start any new threads on our new
site at https://forums.sqlteam.com. We've got lots of great SQL Server
experts to answer whatever question you can come up with.
| Author |
Topic |
|
Pace
Constraint Violating Yak Guru
264 Posts |
 Posted - 2007-02-15 : 05:06:16
|
Hello Experts! I was wondering, im am trying to fire the DBA, basically he has never even heard of the word normalisation, and many of the tables consist of 150+ columns... there is repeated data everywhere... its a mine field and really messy. Many times I have had to add a PK to a table, there isnt one FK in the whole DB and the only index's are on the PK's... Basically, can I do a TSQL query, on a table, to return the column names that contain nothing but nulls. You should see some of them, if you open the table from the MMC you can see pages and pages of nulls. We have a customers table where yup, we hold customer info, which we then duplicate for every quote, every time  you'd never have guessed it but if the quote goes ahead, we dupe it again for the job. So can you help me with this query so I can get rid of coco  he works for cash and not love and its upsetting me that he is still coding. We have all our depts and he will make the table say something along the lines of Accounts, [Accounts OK], Purchasing, [Purchasing OK], HR, [HR OK], [UK Sales], [UK Sales OK] .... for like 8 depts. By the time its finished, it will hold 7 columns worth of info yet the table will be some 56 columns wide... I was wondering what was wrong with having just the 7 columns and having Dept, DeptOK but ya know... Basically I am trying to chop the app with everything that isnt used to say to management, well this is what you actually use, this is your structure, this is what it could be and this is why... not to mention the fact he gets paid almost twice I do..."Impossible is Nothing"  |
|
|
Kristen
Test
22859 Posts |
Posted - 2007-02-15 : 06:28:33
|
| "we hold customer info, which we then duplicate for every quote"Not to rain on your parade! but is there a need to know what the customer's details were at the time of the quote?We store Customer Address details in every order and invoice, and only their latest info in the Customer table. We could store a history of changes, and link from Order/Invoice to that, but lots of changes to that table are fixing typos, or cosmetic, and aren't actual "revised versions" IYSWIM ... so we decided to store the data in duplicate on documents where it mattered.Mind you, we don't have 150 columns, we do have PKs and FKs and secondary indexes. So I'll not watch my back just yet!Kristen |
 |
|
|
eyechart
Master Smack Fu Yak Hacker
3575 Posts |
Posted - 2007-02-15 : 10:20:50
|
| sounds like you need to fire the developer instead. The DBAs primary job is to ensure that the data is available and (if needed) can be recovered. Fire him if he isn't doing that.design issues like you have described are the fault of the developer. Many times developers will bring the DBA in for consultation, but application design is not the role of the production dba.Most problems can be solved simply by firing a few developers. It is also kind of fun. Try it, you'll like it.-ec |
|
|
|
Michael Valentine Jones
Yak DBA Kernel (pronounced Colonel)
7020 Posts |
Posted - 2007-02-15 : 11:20:18
|
quote:
Originally posted by eyechart...Most problems can be solved simply by firing a few developers. It is also kind of fun. Try it, you'll like it...
Don't forget to fire some of their managers too!CODO ERGO SUM |
|
|
|
ProEdge
Yak Posting Veteran
64 Posts |
Posted - 2007-02-15 : 15:51:50
|
quote:
Originally posted by eyechart
sounds like you need to fire the developer instead. The DBAs primary job is to ensure that the data is available and (if needed) can be recovered. Fire him if he isn't doing that.design issues like you have described are the fault of the developer. Many times developers will bring the DBA in for consultation, but application design is not the role of the production dba.Most problems can be solved simply by firing a few developers. It is also kind of fun. Try it, you'll like it.-ec
In some companies though, the DBA is also the developer of the databases. I don't know what the case is here but if the DBA is both, that's a problem. |
|
|
|
raclede
Posting Yak Master
180 Posts |
Posted - 2007-02-15 : 22:10:08
|
| For me DBA should be responsible for the architecture of the DB so go ahead fire him... In our company developers design the table structures but we consult the DBA in order to check if we are following best practices in DB design. |
|
|
|
eyechart
Master Smack Fu Yak Hacker
3575 Posts |
Posted - 2007-02-16 : 05:22:35
|
quote:
Originally posted by raclede
For me DBA should be responsible for the architecture of the DB so go ahead fire him... In our company developers design the table structures but we consult the DBA in order to check if we are following best practices in DB design.
Not all shops are going to have a development DBA though. Where I work, there is so much to do that we cannot oversee all design decisions. This is left up to the developers. We help out when we can, or when we are asked, but we don't have time to look at everything.-ec |
|
|
|
rockmoose
SQL Natt Alfen
3279 Posts |
Posted - 2007-02-16 : 11:40:58
|
| Our policy is that the developers are not allowed to use NULL anywhere, unless it is sanctioned by the DBA...Maybe you can transfer him to the excel department.rockmoose |
|
|
|
|
|
|
|
|
Fire the DBA