June 25, 2008 at 6:40 am
As a 25 year professional, I've been long concerned about the lack of understanding of relational databases and the systems that they run on - both the logical part and the physical implementation.
I am more concerned that all programmers are now asked to design and write database code. Even on platforms where traditionally, only well trained pros did work, I am seeing issues. I'm used to badly written stuff on SQL Server, but not on Sybase. Not because of the RDBM product, but because of the skill of the developers - who may be excellent Java or SharePoint developers, but not database.
And fixing it, unfortunately, usually means "add hardware" - because it's cheaper than adding database pros.
Roger L Reid
June 25, 2008 at 6:56 am
I have seen the same thing, developers are good at what they know but some of them design databases that are completly un-scalabe and un-normalised, they grind to a halt when a lot of data is added. By this stage they are usually working on another project and it is up to the DBA to sort out the mess.
June 25, 2008 at 10:18 am
Sometimes it's cheaper. Other times it means hiring a consultant or another job for one of us.
Look at those "mistakes" as opportunities, and it won't seem so bad.
June 25, 2008 at 10:43 am
Steve -
Here's the difference: I'm on salary. And it's not a bad salary.
If I were more of a risk taker, I'd jump to consulting. I'd probably have more fun and make more money. But the small chance of going broke or being utterly miserable gets me.
I used to be a pretty fair database designer, coder, and tuner. But since I COULD run the dataservers, I did. And that's become a more than full time job. On salary.
There's a real need for someone to work with developers, in the early stages. They'd appreciate it, and I'd enjoy it, and the results would be better.
I tend to come in at the point (you all know this one) where what they really need to do is fix the schema, but they "don't have time" - so they need an expert simply because s/he's the only one who can figure out how to distort the queries with outer joins on substrings and unions on selections full of casts just to get a simple answer.
Doing that is a GOOD day, even so.
Especially if I don't have to explain that your deadlocks don't mean the server is broken, but that you should follow a few simple principles when writing multi command transactions - which is where this thread started.
Anyway - I get your point. It's an opportunity if I would jump at it. I sure thought about it, especially after I had my non-disruptive Sybase<> SQL Server sync utility (in Perl, of course) working so well.
I guess I like the regularity of a paycheck (my spouse is a consultant).
Roger
Roger L Reid
June 25, 2008 at 2:54 pm
After seeing many, many bad coding, bad database designs and even bad DBA management, I can only come up with one thing. You care about your job and you think the other people would do the same thing. The fact is a lot of people just care about the paycheck.
The only thing that makes me upset is those people get the same paycheck as you do !!!!!
Actually as being a woman programmer, I see so many male counterparts get more money than me and they do such a lousy job and even get the promotion !!!!!!
I should shut up, I think I complain too much!!!!!
June 25, 2008 at 3:36 pm
R L Reid (6/25/2008)
As a 25 year professional, I've been long concerned about the lack of understanding of relational databases and the systems that they run on - both the logical part and the physical implementation.I am more concerned that all programmers are now asked to design and write database code. Even on platforms where traditionally, only well trained pros did work, I am seeing issues. I'm used to badly written stuff on SQL Server, but not on Sybase. Not because of the RDBM product, but because of the skill of the developers - who may be excellent Java or SharePoint developers, but not database.
And fixing it, unfortunately, usually means "add hardware" - because it's cheaper than adding database pros.
It's all a matter of "training"... and I'm not talking about the Developers. For SQL Server in particular, most managers think a database is just a place to store data... and that's the real problem. The GUI reigns supreme in most managers eyes. A good number of them have no clue what a database actually is or how it should be used. As a result, they let non-qualified programmers write db code and design databases. You can easily find out who these people are... ask them, if they were to design a database, how many types of telephones numbers should be stored in the Customer table... 😛
--Jeff Moden
Change is inevitable... Change for the better is not.
June 26, 2008 at 6:17 am
'Training' - my old IT director said SQL is so easy, anyone can do it why bother to send anyone to training?
What does management know ? This is what IT has to fight for all the time.
They think database is database, SYBASE, SQL Server, Oracle.....they are all the same.
Someone should put some sense into those guys!!!
my 2 cents
June 26, 2008 at 6:49 am
Loner (6/26/2008)
'Training' - my old IT director said SQL is so easy, anyone can do it why bother to send anyone to training?What does management know ? This is what IT has to fight for all the time.
They think database is database, SYBASE, SQL Server, Oracle.....they are all the same.
Someone should put some sense into those guys!!!
my 2 cents
Sounds like a dangerous thing for an 'IT Director' to say
Do other people in your organisation get training?
June 26, 2008 at 9:46 am
I think you need to stop looking at design because people are always in a hurry. The developers don't want to do a bad job, but they want to get finished. And there's value in that.
Instead, focus your efforts on refactoring and teaching small lessons. Show them how a change might help them or speed things up. How to think about indexing. You might be surprised how they "slip" in those changes as they move along and slowly you end up with a better application.
I came into a startup at about month 5. They already had a schema that was so-so, but had issues that would appear as loads increased. So I started looking at what I'd do ideally and then trying to figure out how to get there from here. I worked with developers and explained where and why I thought they made mistakes, or where they might get into trouble.
I was kind of a nazi DBA, insisting on total control for access to production, so I had to work to show the developers I wasn't trying to be a jerk, but rather ensure things went smoothly. Slowly over time we implemented some of my changes, and suffered through other design flaws.
And I think the developers learned a lot over time. I'd like to think they went on to do better at other jobs.
June 26, 2008 at 12:23 pm
The IT Director works for a fortune 500 bank, right now the bank is in big trouble. No one got any training for SQL Server or Oracle. They used both databases.
Recently I was contract with a startup. The company exists for 8 years already and they are using SQL Server. There is no DBA ever. The developers who write all the SQL queries are .Net web developers. The database design was horrible. The SQL queries were inefficient. However even they hired me trying to clean stuff up but they are in a hurry to get things done. It ended up cleaning up the database was not their top priority. Whatever I suggested I was not able to do, so I decided to quit and found another job.
Actually in both cases all the database development were done by web developers. The management just wanted to get the project done within the deadline and it was working, they did not care about the database design and how the developers wrote the query.
June 26, 2008 at 12:40 pm
Steve,
You're quite right about small lessons.
I was amazed the day a co-worker (one of the most db-savvy, but very set in his ways) decided that stored procedures were "worth the extra effort".
Or the day a systems adminstrator called and said that in 2 weeks they were installing a 3rd party product for eval, and they'd like me to review the SQL Server requirements ahead of time.
All because I kept insisting these were good things even though I thought no one was listening. (Of course, then along came SharePoint...)
roger
Roger L Reid
June 26, 2008 at 5:22 pm
Steve Jones - Editor (6/26/2008)
I think you need to stop looking at design because people are always in a hurry. The developers don't want to do a bad job, but they want to get finished. And there's value in that.
There's that "time to market" justification, again. And, I don't mean to pick on you, Steve, because you're not the only one saying it. If it's broke and you ship it, you have to fix it on a "recall" basis and you and your company end up looking like the idiots whether you are (why did you ship it if you knew it was broken? Calculated risk and you calculated wrong) or not.
People put way too much value on "finishing" something instead of doing it right.
We're going through that at work right now... our company hired some 3rd party company that's renowned for getting things done quickly... when they delivered, it was so screwed up that we now have to rewrite it in house... and the same idiots that made that decision haven't changed the final delivery date so AppDev boys and girls are working 16 -20 hour days so they can get it "finished" in 2 weeks. They somehow think it might actually work right... won't happen because if you want something real bad, that's the way you get it. 😉
--Jeff Moden
Change is inevitable... Change for the better is not.
June 27, 2008 at 9:26 am
Loner (6/26/2008)
Actually in both cases all the database development were done by web developers. The management just wanted to get the project done within the deadline and it was working, they did not care about the database design and how the developers wrote the query.
This interests me because I'm pursuing a degree in web development, so I'll be one of the hated 'web developers', unless, like the rest of the world, I don't actually use my degree as I thought.
While I'm quite clear on the fact that good db design and implementation will make my future life easier, I'm not sure my classmates are, and some of the projects that we all work on are atrocious when you learn that someone you're in class with is set to graduate. (I'm in my third quarter, so I still have an excuse - not :P)
You work on yelling at them from the DBA end, and I'll change those nasty web developers from the inside. SQL mole, that's me. 😎
---------------------------------------------------------
How best to post your question[/url]
How to post performance problems[/url]
Tally Table:What it is and how it replaces a loop[/url]
"stewsterl 80804 (10/16/2009)I guess when you stop and try to understand the solution provided you not only learn, but save yourself some headaches when you need to make any slight changes."
June 27, 2008 at 9:48 am
Steve Jones - Editor (6/26/2008)
I think you need to stop looking at design because people are always in a hurry. The developers don't want to do a bad job, but they want to get finished. And there's value in that.
This kind of resonated with me the other day. I certainly don't think it's the devs' fault per se, but it's a failure in the process somewhere (under-resourcing/unrealistic plans).
I was interviewing with what turns out to be a remarkable organization, which seems to have an astounding setup. Without getting into specifics, let's just say that they work hard to nip that "hurried" attitude. The Architect was fairly pointed about it: the hurried attitude is one of the first things causing garbage to be produced, and then pushed through, and then undertested, and then not QA'd, and then in production....where it haunts you for ever.
His take on it was: development cycles should be taken a bit like fire drills. Being deliberate, organized and thorough is far more important to overall project completion on time and under budget, than rushing to continuously catch up to some frenetic dev schedule.
Meaning - know you need to get from A to B, but do NOT compromize on the best way to get to B. And then, figure out where C is...
----------------------------------------------------------------------------------
Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?
June 27, 2008 at 10:23 am
Instead, focus your efforts on refactoring and teaching small lessons. Show them how a change might help them or speed things up. How to think about indexing. You might be surprised how they "slip" in those changes as they move along and slowly you end up with a better application.
I completely agree with this. I've found a quick e-mail to the group works well. I guess I'm lucky to have a bunch of developers who take the information on board and use it for future SQL coding.
Viewing 15 posts - 1 through 15 (of 20 total)
You must be logged in to reply to this topic. Login to reply