November 5, 2007 at 9:16 am
I dont know if I'd say its stupid not to use stored procedures. For really fast development using Hibernate or similar ORM tools can make a lot of difference on how fast you get there, though I'd only recommend that approach for apps you know will have a lower number of users (lots of trivial apps get done in corporate America).
Not arguing that stored procedures arent a valuable layer in the process, but they don't have to be used to do access well, or even sufficently good!
November 5, 2007 at 9:49 am
"To me that indicates that people new to SQL Server aren't being trained very well or that too many people building applications aren't concerned with the basics of good design."
I know you're in the training business, Steve and Andy, but I didn't have any formal training in anything to do with SQL Server until I had been working with it all day, every day, for about three years. And then I had a five day class (with Kalen Delaney). That was probably nine or ten years ago. I haven't had an employer offer to pay for training since. I have been part of mass layoffs several times, though, where no executives have lost their jobs or bonuses.
November 5, 2007 at 10:16 am
Every time I hear about how DBAs tend to be arrogant and difficult to work with, I sympathize a little because I know I've been like that before. But as the guardian of the company's data, I think it's important to maintain control and enhance stability. I also think it's better to write a little more code than hope hardware keeps up.
I think this is where the friction between DBA's and the rest of the company starts - when a DBA thinks of themself as simply "the guardian of the company's data" There is no point in guarding data if it is never used.
Maybe DBA's should think of themselves as the providers, to the rest of the company, of accurate data. Maybe management should reward DBA's on the basis of how much accurate data they can provide to support the companies objectives and strategy. Simply keeping data secure is not enough.
November 5, 2007 at 10:20 am
Oh, I definitely did not mean to imply that people shouldn't think about design; regardless of what scale you are building on, or how small or large your user base, you need to have some sort of strategy, some sort of high-level approach.
But in my experience, today, individuals and teams are so affraid of any changes during development/implementation that they tend to focus on comprehensive analysis/design/planning (and that overused terrible term "architecture") to the detriment of all else. The cost of evolutionary change is lower than ever before, yet development processes are more rigid than ever: it's as if IT has now (finally) mastered and institutionalized the best possible development approach for a world of batch processing and punched cards.
Regarding skill, yes, this is a key point: in order to make use of the opportunities and lowered cost offered by today's wonderful tools and environments, one needs to be skilled with one's toolset. Developers at least need to know that they shouldn't use a screwdriver as a prybar before they make the conscious decision to ignore the guidance -- big difference between conscious and unconscious ignorance.
As a concrete example, in my world, we make a very conscious decision in application development to do things that very much degrade the performance of the database server. And our DBA is completely on board with this. The reason? In our specific situation, doing this greatly (orders of magnitude) improves applicaiton performance and lowers costs (networking and point of use systems). In this example (and there are many, many like this), had we followed the modern planning/architecture approach, we would have ended up with a system that took far, far longer to deveop (wouldn't be done yet!), at far greater development cost, with far larger initial and operating costs. Then again, that approach would have yielded a masterpiece of a multi-thousand page architecture and plan document.... (Of course, in the alternate approach, my team of two highly skilled local developers would be replaced by an outsourced hoarde of offshore developers, which may thus come with another set of tradeoffs.)
November 5, 2007 at 11:04 am
"Pay you now or pay you later." How about pay you never? I work in a place that can't afford real DBAs, not even as occasional consultants. They have me and that's it. I design and maintain the databases, then create the applications, write the user documentation, train the users, etc. I AM the DBA. I AM the developer.
I think of myself as something of a generalist. There is no doubt in my mind that a specialist trained in database development would be able to improve on my designs. However, given that we have such slow growth (comparatively), such relatively good performance right now, and such a very small budget, it is possible that we will never bring in a DBA. Or if we do, it will be one of those situations that is long after the problem is a problem.
So, it is up to me to train myself as much as possible given all my other duties. This is why I look at SQL Server Central among other things. I agree that good training for me is vital. But getting that training is not always so easy. My time aside, it seems like I see a ton of articles that say how important say good query tuning is, but that don't actually give concrete details on how to do it. It doesn't help to talk about what an art query design is without specifying how to build skills in that art.
Maybe I'm just looking in the wrong places. My point is that there are situations out there where having access to a DBA is simply not an option, now or in the future. Ten years down the road, our apps are still working fine. There's no reason to call in the consultant. In these cases, it seems like the discussion should be framed differently than call in the DBA now or pay twice as much later. Alas, I don't have a good frame.
November 5, 2007 at 11:49 am
JJ B (11/5/2007)
"Pay you now or pay you later." How about pay you never? I work in a place that can't afford real DBAs, not even as occasional consultants. They have me and that's it. I design and maintain the databases, then create the applications, write the user documentation, train the users, etc. I AM the DBA. I AM the developer.
JJ - the way I was reading the quote was "Plan now, or pay (the piper) later". Meaning - design your project right or pay for it later, cause Murphy and your user community will come for a visit. Outside consultants are just one way to fix those issues.
The fact that you even care to go out and keep seeking for the right/best/fastest/most scalable way means that you're ACTUALLY wearing the DBA hat, which means you're heading in the right direction. I've been in your shoes for a substantial portion of my career as well: no DBA to back me up, so I become the DBA as well as a few other roles. Not holding the title doesn't mean you don't fit into the role.
----------------------------------------------------------------------------------
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?
November 5, 2007 at 11:54 am
Matt:
You have a point. Thanks for your reply.
- JJ
November 5, 2007 at 11:57 am
I've definitely a part of the training business, but you don't necessarily need formal training to learn how to do things well. Regularly reading, buying a few books, even debates like this are a great way to learn.
DBAs can be hard to find or budget for and if you can't get one, then places like this and other sites are one way to get similar advice.
There is no right way, but you always have alternatives, so it pays to think and consider them before moving forward.
And I do agree with Sir SlicenandDice. You need to do what's best for the users and application, not necessarily any component.
November 5, 2007 at 2:53 pm
Robert W - bravo! Nice post.
November 5, 2007 at 5:39 pm
Tuning being the topic and DBA's seem to be the target. Sorry, but umbrance taken. As a DBA it mostly falls to me to do the forensic investigation on the issues with an application. Unfortunately, I see the same coding practices the are known 'Bottlenecks' used time and time again because it is expedient. As I have also played in the Development arena and DBA three ringed circus long enough to know that developers get very possessive regarding their 'baby' and take exception to having a 'Humble DBA' tell them that their solution is the cause of the 'Slowdown'. This critique seems to portray the 'arrogant DBA' persona. Unfortunately, the cause it not that the developers don't care or DBA's are arrogant but, expediency. Not being allowed the time to explore different techniques, new technologies. The expectancy to produce a quick result, and if that means triggers running cursors around select statement which don't use some sort of intelligent index then so be it. But don't expect me to endorse your solution. Here are a couple of reflection points.
1. If your solution requires Cursors, there is a better way
2. If your solution uses triggers - Caution these are as ravenous as cursors.
3. Just because you can, doesn't mean you should.
4. Use Peer review.
Finally
If its quick and dirty, it's usually the DBA that has to wipe it's Bum !
CodeOn 😛
November 5, 2007 at 5:43 pm
Andy Warren (11/5/2007)
I agree that taking on debt around performance isn't a good idea, and Im not advocating bad design from the start either!As a consultant its rare that Im called before the problem happens, and often they have been successful for quite some time. Then it tips over, they call someone in that does some degree of magic and makes some recommendations for the future, off they go for a while longer! As a trainer I advocate DBA's being very connected to the developers as a coach & mentor when it comes to data access & design, but often its not up to them. The ones that seem to be most successful are the ones with the charisma to push their way in without seeming like they are pushing their way in.
I find its not often that devs don't listen as much as they are so rarely told anything at the point in the dev cycle where it could be changed. The question for the industry is how do we get someone involved in the data model early on so we don't wind up with a mess later?
Now, we're talking! I absolutely agree with all of that. I'll also throw in that Managers should be brought into the mix of training concerning the quality/performance of code, technical debt, and the risk of collateral damage... Heh, maybe that training session should be called, "If you want it real bad, you'll probably get it that way!" 😛
--Jeff Moden
Change is inevitable... Change for the better is not.
November 5, 2007 at 6:01 pm
JJ B (11/5/2007)
"Pay you now or pay you later." How about pay you never? I work in a place that can't afford real DBAs, not even as occasional consultants. They have me and that's it. I design and maintain the databases, then create the applications, write the user documentation, train the users, etc. I AM the DBA. I AM the developer.
I absolutely agree with how Matt responded to this, JJ... the reason why your apps and data still work after 10 years is because you did take some time to do it right and, even now, you continue to learn as do we all.
I am a bit jealous over having total control over your own environment... I also remember the dedication that took... well done!
--Jeff Moden
Change is inevitable... Change for the better is not.
November 6, 2007 at 12:44 am
rudy komacsar (11/5/2007)
Since DBAs are usually left out in the early formative stages of a project like requirements gathering, software selection and hardware acquisition and setup you get just that.
That sounds familiar.
Where I work I keep finding out about new applications they go live. Way too often I look at them only to find poor db design, appalling queries, useless indexes and hardware that is so underspeced that my laptop would massivly out-perform it. :angry:
When the users complain, guess what. They scream at the DBA team. It's all our fault. Ignore the fact that we don't get consulted on hardware or design issues, ever, and that servers may not be upgraded within 3 years. (Company policy). Ignore the fact that I'm not alowed to touch databases belonging to vendor products, other than to do backups
I've had a BA yelling at my manager, telling him that we're incompetant because we can't get one simple db running fast. Upon a quick check, the 'server' that the db was on was a Pentium 2 (single processor) with 512 MB memory. Running Windows 2003 enterprise and SQL 2000. Gee, I wonder why it's slow.
And people wonder why I'm going slowly crazy here. :crazy:
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
Viewing 13 posts - 16 through 27 (of 27 total)
You must be logged in to reply to this topic. Login to reply