May 11, 2009 at 10:27 am
For the record, I'm an application developer first and a database developer second (as determined by time devoted to each category), but I took no offense. To the contrary, my personal experience has been that many, if not most, of my fellow developers aren't terribly adept at db development and maintenance.
But that's not necessarily the problem. It's the ones who don't care (at the expense of their customers) that get my goat. Such developers are more prevalent than some want to believe. Those who don't fall into this category (i.e. developers who do care about proper db admin/development) have no reason to take offense at Steve's reasonably accurate assessment.
May 11, 2009 at 11:54 am
Steve Jones
This thread was designed to highlight things that developers commonly do wrong
Let me define what I understand a Developer task - who who develops interface code NOT one who develops SQL code, defines tables, etc.
Having been a developer, I strong resent the assumption that developers are at fault for a poorly executed DB project. I will state clearly that it is management that makes the mistake. All too often management is composed of bean counters (accountants) or those with a degree in management science who have not a shred of technical understanding, or how to manage a technical project. Managers who allow coding and database design to proceed without a shred of documentation, starting with what the results of the project should be, who will be using the developed code/database, what will be the data input, etc., etc. In other words without a formal specification.
They then compound the issue by not having specific software and database designs documented. Since they lack the necessary foundation upon which to build they never plan to hold review meetings, where developers and DBAs present and discuss their respective designs and modify each where necessary.
To sum it up they fail to see that the project requires a team effort where developers and DBAs work together exchanging ideas and each part of the team does what they do best.
Last, but not least they fail to appreciate that each group, developers and DBAs, learn the others strengths / weakness so that the next project proceeds to a successful completion at the least cost.
May 11, 2009 at 11:59 am
No assumptions, bitbucket, on the success or failure of a project. This is at a lower level of where developers make mistake in the coding, not in interpreting the requirements or executing them.
May 11, 2009 at 1:34 pm
Bob Lee (5/8/2009)
Amen to the injection. Field validation in the applicaiton is a biggy.Databases are often used as spreadsheets. Just like developers are taught in school. Data access can be an art form too because all record sets are not sized equally. A DBA can help the developer here. We often know the data better than the application developer but are clueless about the application. It changes but those changes aren't uploaded to the DBA's KB.
I think that we could spend some quality time with our developers and not looking at them as the impediment but as an opportunity to tout our benefits.
SELECT * FROM DEVELOPERS WHERE CLUE IS NOT NULL;
Best way to resolve the query above is to lend a hand or to "insinuate" yourself into the development process from the very begining. Involving the DBA with the business side of the application as well as the data is a winner.
Bob
Gila, I have to apologize. There is some good DBA's out there and yes, I was wrong about the blood. I went back through this thread and read through the posts again until I came upon this jewel of a post which I had missed. This is what I have been saying in the past. I know there are in every profession those who have either not been properly trained or they just try to do the job to get it done regardless of what end users of their product/work have to endure.
Bob, you said it. Developers that do it wrong need to be told they do it wrong and not cut out off the process. I will be the first one to admit that I had written some code in the past that makes my hair stand up. Fortunately, I had people that were willing to show me the way.
Steve, sorry for my rants. I will count my words next time!:hehe::hehe::-D:blush:
:-PManie Verster
Developer
Johannesburg
South Africa
I can do all things through Christ who strengthens me. - Holy Bible
I am a man of fixed and unbending principles, the first of which is to be flexible at all times. - Everett Mckinley Dirkson (Well, I am trying. - Manie Verster)
May 11, 2009 at 2:09 pm
If you want a rant - http://sqlinthewild.co.za/index.php/2009/04/17/developers-vs-dbas/
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
May 13, 2009 at 12:28 am
GilaMonster (5/11/2009)
If you want a rant - http://sqlinthewild.co.za/index.php/2009/04/17/developers-vs-dbas/
Very nice Gila, I like this way of thinking. I think everybody can go and have a look at this discussion. Working together rather than against each other makes sense.
:-PManie Verster
Developer
Johannesburg
South Africa
I can do all things through Christ who strengthens me. - Holy Bible
I am a man of fixed and unbending principles, the first of which is to be flexible at all times. - Everett Mckinley Dirkson (Well, I am trying. - Manie Verster)
May 13, 2009 at 12:30 pm
Manie Verster (5/11/2009)
GilaMonster (5/11/2009)
Manie Verster (5/11/2009)
I never see any articles about bad DBA's, no sirree. They are the good guys. The people that so arduosly defend their databases against developers that will come in like viruses and destroy their databases.
Maybe you didn't read my comments (Posted 5/8/2009 3:15:16 PM) - the first thing pointed out there is that the really serious errors that developers make are just the same as the really serious errors that DBAs make. ANd I make the particular point that more DBAs write row by row stuff than developers (because the developers never went on any of those really awful courses for DBAs that pay more attention to understanding cursors and all their beauties and complexities than to sets.
I don't think that the editorial had any anti-developer bias: if I had thought that I woul have had a few rude things to say. I did think that some of the comments were rather anti-developer and showed a stupid attitude, but you can't blame the original editorial for that. Maybe the editor should have guessed that he would get some comments of that sort - but whatever you write is going to provoke some idiot responses as well as lgood responses, so is the answer never to write anything?
Tom
May 15, 2009 at 2:48 pm
Tom.Thomson (5/13/2009)
Manie Verster (5/11/2009)
GilaMonster (5/11/2009)
Manie Verster (5/11/2009)
I never see any articles about bad DBA's, no sirree. They are the good guys. The people that so arduosly defend their databases against developers that will come in like viruses and destroy their databases.Maybe you didn't read my comments (Posted 5/8/2009 3:15:16 PM) - the first thing pointed out there is that the really serious errors that developers make are just the same as the really serious errors that DBAs make. ANd I make the particular point that more DBAs write row by row stuff than developers (because the developers never went on any of those really awful courses for DBAs that pay more attention to understanding cursors and all their beauties and complexities than to sets.
I don't think that the editorial had any anti-developer bias: if I had thought that I woul have had a few rude things to say. I did think that some of the comments were rather anti-developer and showed a stupid attitude, but you can't blame the original editorial for that. Maybe the editor should have guessed that he would get some comments of that sort - but whatever you write is going to provoke some idiot responses as well as lgood responses, so is the answer never to write anything?
Tom, you did not read very well. I will quote myself below where I said that:
Steve, you said that you did not mean to generalize or to degrade developers here (can't remember you exact words) but there are people (DBA's) that log on to this site and generalize and absolutely slaughter the developers.
and if you checked further on page 10 I posted an apology for my rants. Allow me to apologise again here. I am really sorry for the things I said. Someone said to me one day that if people anger you then they anger you and for a moment there I allowed these people to control me. I hope that I will remember this the next time before I allow people to anger me.
:-PManie Verster
Developer
Johannesburg
South Africa
I can do all things through Christ who strengthens me. - Holy Bible
I am a man of fixed and unbending principles, the first of which is to be flexible at all times. - Everett Mckinley Dirkson (Well, I am trying. - Manie Verster)
November 26, 2013 at 3:06 am
I am a BI developer first and foremost, but spent 100% of my time working in and with SQL Server.
I QA a lot of code before it is released to production and the thing I come across very frequently is 4 part object referencing using hard coded server and database values, or even in some instances 3 part object referencing - even when the object is in the same database as the reference. To highlight the issue I enforce a rule that databases must be suffixed by the environment they reside in (eg. _Dev, _UAT, _Prd). This certainly highlights the issue as the database moves up to the next environment.
This issue first came to light in a database called XX_PROD which contained a lot of 3 part references to itself. This meant that the database had to called XX_PROD whichever environment it resided in - including dev and UAT. Bonkers!
We have several databases that cross reference other databases as are all a part of the same BI app (ODS, meta data, data mart), either on the same or on different instances. This is where SQL aliasing, linked servers referring to the alias, and synonyms come in very useful.
And please don't join a table in one database to another table in another database, especially if they are hosted on different instances.
November 26, 2013 at 3:17 am
I have recently blogged about 10 common mistakes Java developers make when writing SQL. These mistakes apply to all other developers (including SQL developers) as well, of course:
http://blog.jooq.org/2013/07/30/10-common-mistakes-java-developers-make-when-writing-sql/[/url]
http://blog.jooq.org/2013/08/12/10-more-common-mistakes-java-developers-make-when-writing-sql/[/url]
November 26, 2013 at 4:05 am
Clustered index on Identity column, due to MS automatically creating clustered idx on PK, when that clusteridx is much better on TradeDate or AsOfDate. The whole full vs. simple recovery "out of the box" kills a lot of people too when they run out of disk space due to a huge ldf.
November 26, 2013 at 4:14 am
lukas.eder (11/26/2013)
I have recently blogged about 10 common mistakes Java developers make when writing SQL. These mistakes apply to all other developers (including SQL developers) as well, of course:http://blog.jooq.org/2013/07/30/10-common-mistakes-java-developers-make-when-writing-sql/[/url]
http://blog.jooq.org/2013/08/12/10-more-common-mistakes-java-developers-make-when-writing-sql/[/url]
I was looking at your blog posts and thought I'd point out a slight error in the second. Number 4 (4. Using pre-ANSI JOIN syntax) is slightly incorrect. These joins where the from clause lists the tables as Table1, Table2, ... are actually ANSI-89 style joins. Personally, I hate them. I started working with SQL Server 6.5 back in '96 and I always used the ANSI-92 style joins. It separates the join criteria from the filter criteria.
November 26, 2013 at 4:19 am
I was looking at your blog posts and thought I'd point out a slight error in the second. Number 4 (4. Using pre-ANSI JOIN syntax) is slightly incorrect. These joins where the from clause lists the tables as Table1, Table2, ... are actually ANSI-89 style joins.
Nice catch. The heading should read "pre-ANSI-92", not "pre-ANSI"
November 26, 2013 at 6:53 am
I found this topic very interesting given what I've been dealing with in the last couple of weeks.
I inherited a pretty small data warehouse and am the lone database developer. In one of our databases there are two tables that are the primary source of information for reporting and querying. These are relatively small tables in the number of records but they both have a significant number of columns, 83 and 99 respectively.
Both tables are truncated and refreshed daily. I discovered that both of these tables had an index on EVERY COLUMN! The table with 99 columns was only loading about 3,300 records but it was taking almost an hour to do so. I spent about a day and half cleaning up the indexes and now it loads in less than 10 minutes.
If you don't understand something please take the time to educate yourself on the subject before you jump into the fray. You (your career), your company and your data will be better served by taking the extra time to learn about what you should do before you try and do it.
Regards
November 26, 2013 at 7:07 am
The most common issue related to SQL I've found during my career is having developers that don't know (and don't care) about SQL; form far ago SQL Server 6.5 overabuse of cursors to the ORM-generated unpredictable data access patterns, they all have in common that the developer doesn't know where he is working upon and uses a inadequate approach or delegates completely this layer to the framework in voge.
Viewing 15 posts - 91 through 105 (of 113 total)
You must be logged in to reply to this topic. Login to reply