April 26, 2008 at 2:29 pm
Comments posted to this topic are about the item Easy or Hard
April 28, 2008 at 1:25 am
I think Steve sums it up with the phrase, "the tools we use should be ergonomic, but not simplistic". I can think of no instance where making something easier to use has been a bad thing, but something simplified does not necessarily equal something made easier.
It's worth bearing in mind, though, that installing SQL Server and using it are two distinctly different tasks. It'd be quite reasonable to ask substantially more questions during an install and cut down on the number of defaults used, since installs are (or should be) carried out by more experienced people. It'd also be patently obviously unacceptable to make the standard administrative GUI tools any less slick to use, because that'd just waste valuable time.
So personally, I'd maintain a certain "barrier to entry" in terms of keeping the installation process a relatively intense one, but make the administrative tools as ergonomic as possible.
Semper in excretia, suus solum profundum variat
April 28, 2008 at 5:59 am
Personally I think SQL 2005 Mgt. Studio does not flow as easy as 2000 Ent. Manager did. Mgt plans, Import/export, Jobs, granting select to users for individual tables, etc. I don't like not having Query tool without installing Mgt. Studio.
I am all for simple design, however I do see the point of not too simple and the danger of simple means anyone can install and use SQL Server and implement bad designs. However, don't we as a society tend to make things simpler over time for ALL things ?
Who hand cranks the starter on a car anymore, who changes the tubes in a TV. There are downsides to dumbing down some things, yes, however, SQL Server built its user base somewhat on ease of manageability too.
April 28, 2008 at 6:50 am
Database *administration* as a profession is a *stupid* idea. It came about because databases never emerged from Phase 2 of the design process.
(Phase 1 - make it work *at all*, Phase 2 - Make it work *well*, Phase 3 - make it work *right*).
The previous poster made my point. Do we still hand-crank our cars? Do we still implement our own sorting algorhythms? Do we create our own indexing infrastructure?
Then why should we have to implement our own performance tuning? SQL Server has made great strides in this area over the years. Sure, it will never be brainless, and we'll always need DBAs for database *design*, but doing day to day operations should be either automatic or so simple an entry-level person should do it.
It shouldn't take a $100,000/year employee to run a database. Once it's set up it should work. Doing backup, doing restores, fixing errors bugs in the database engine cause, all these should be simple and straightfoward. Enough so that entry-level people (shown how) can do them reliably.
So the *less* complexity in a database, the better. At least the less *exposed* complexity. We don't have to worry about translating physical disk sector location into file names, why should we be stuck trying to balance file groups?
There's too much to do. Let the computer do what it's good at and leave the hard stuff to humans.
April 28, 2008 at 7:06 am
I think creating barrier to entry is the wrong way to go. Sure, it makes it easy to write bad software (see my signature), but nothing we do will ever stop that.
How often does bad software written by amateur programmers (including database designs and crappy stored procs):
Result in someone being maimed or killed?
Cause the destruction of millions of dollars worth of property?
Cause children to grow up without living parents?
Result in true human terror?
I have to say, it's not very often. But all of the above can be caused by a simple knife. Does that mean we should make knives more difficult to use? Does that mean we should make it impossible to open the packaging on a knife without an expert available?
Personally, I see it as a cost/benefit situation. Sure, some really crappy databases get built. But a lot of small businesses, with "my neighbor's kid is good at computers" type databases, get a lot of value out of those. Some are more expensive than they're worth, but many, probably most, are worth more than they cost. That's really the only measure of any business investment, so I see the low barrier to entry, the ease-of-use, the simplicity of installation, as positive things.
But I have to admit to a bit of prejudice in this regard. My background is sales, marketing, and management/executive function. I got into databases because I needed one. Had it been prohibitively difficult to get one started, or to build something that would "do the job", even if it didn't do it as well as it should have, I wouldn't have worked with databases at all. And I don't think I'm that bad a DBA, as it ends up.
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
April 28, 2008 at 7:13 am
I think the thing we need to remember here is that a database server that is running your Enterprise is not in the same class with Office or Windows. For a small business, installing SQL Server with all of the defaults will get them up and running. Some vendors will even take care of automating the administration with little feedback from the user. That works well for small businesses.
When you look at something your Enterprise heavily relies upon, you can't have the accounting department guru install it and just hope it works. It really isn't any different than installing your network. You have servers that must be maintained and installed by folks who know how to optimize the network. If it isn't done right, people won't use it. How about failures? If your database server goes down and you don't have someone readily available to restore it, how much money is lost to people sitting around waiting for the system so they can do their job?
As far as advanced functionality in SQL, I enjoy the ease of use it provides. We are still at the point that defaults work for us since our primary database is only 48GB. SQL 2000 is managing OK and I'm confident that 2005 will be a hero. Something I have found in our environment (I have only been here for six weeks) is old stored procedures written that did not adhere to ANSI standards (using *= instead of OUTER JOIN for example). Without my knowledge of how SQL works, my employer would be stuck with 2000 unless they chose to pay $150/hour for an expert to come in and do their conversion for them.
For day to day operations, any employer might have a difficult time justifying the salaries and benefits paid to a SQL expert. However, the first time there is a crisis or in our case an upgrade, that salary is very easily justified over time. I believe opportunity cost and risk mitigation are the phrases here.
Should it be easier? Absolutely and I support Microsoft in making it easier and smarter. Am I needed? Absolutely. There will always be areas where fine tuning is required. Remember that starter example on your car? That engine still needs to be tuned periodically...
April 28, 2008 at 7:52 am
along the lines of steves comment that 'the tools we use should be ergonomic, but not simplistic' I have always felt that the important thing is that tools should be intuitive to use. If it is not obvious where to go to get to the next stage, or which buttons to push, the tool is failing you. To my mind, EM is more intuitive than SSMS + SSIS, but then perhaps that because SSMS has been steered towards developers even though its a DBA tool primarily.
Tools need to be simple to use but the defaults need to be carefully chosen. How many posts have you seen in this forum that start 'I have just installed SQL and now want to move my system databases.......'
---------------------------------------------------------------------
April 28, 2008 at 8:08 am
I do think that SQL Server makes strides in being more automatic to use with every version, but there are still things that someone needs to decide. For example, the missing indexes DMV. It's great, but you don't necessarily want to automatically create all those. It's possible that you'd get so many indexes that performance in inserts/updates/delete would suffer.
Perhaps there are some counters that could be added for the system to make better decisions, or perhaps the tools could alert people that a decision should be made. Perhaps setup should help people setup mail so that they can get alerts easily from the system. I'm sure there are changes like this.
The one area that makes some sense for the system to handle is backups, especially log backups for full mode. Shouldn't it run log backups automatically if you're in full mode? However a person needs to understand the implications of that for disk space and recovery, especially since those files need to move to another machine.
While it would be nice to have more automation, I think the barrier to entry should still be slightly high until we can easily do more automation on certain tasks, or perhaps come up with good questions that a layman can answer.
April 28, 2008 at 9:00 am
One solution is to have two versions SQL Server. SQL Express and SQL Standard. Express gets most of the features and relies heavily on defaults. SQL Standard would be more for advanced features and experts to use.
Personally, I'm all for making it more automaitc and smoother/easier to use.
April 28, 2008 at 9:19 am
Funny you mentioned the stripe backup and the long standing backup dialog. Just last week I asked one of our engineers to get me a backup. Wouldn't you know he was fearful of messing up the scheduled backup process as when he opened the backup dialog he saw the previous path. He thought well I'll just add my location to the list and it will make 2 copies.... 🙂
Well obviously after he uploaded the bak file and i went to restore i got the wonderful error stating only 1 of 2 or whatever that error is. So i gave him detailed directions. Well this time he interpreted those directions to mean to keep the current backup path and he didn't check the overwrite option so he uploaded me a 5GB backup that should have only been around 2.
To an experienced dba the backup dialogi is simple, but this guy is not a moron, he is a competent engineer but minimal experience with SQL, it shouldn't be that hard to get a good backup. Possibly a message saying you are making a striped backup when there is already a path in the box, or when there isn't and you are about to append, it says you are appending. Then again, I don't want those boxes popping off every time i run a backup when i know what I am doing. (mostly haha)
And yes, i know, i could have sent him a script. 🙂
Jimmy
"I'm still learning the things i thought i knew!"April 28, 2008 at 9:37 am
Hi
There is already a company that follows that model, Oracle. I'm sure I’ve read a number of articles on here suggesting with some justifiable pride that SQL Server DBA's are capable of running many times the number of instances that an Oracle DBA can manage.
From a business point of view the last thing that M$ wants to do is restrict the uptake of its products and the last thing that businesses want is to crank up the costs of supporting an existing infrastructure simply to "raise the bar". The obvious fact is if you want good developers and DBA's set the bar before hiring them. Once they are employed give them every help in making them as efficient and cost effective as possible.
K.
April 28, 2008 at 9:50 am
I think the fault lies in the "packaging" and not in the tools per se. Better automation, slicker UI's, etc... in a sense does in fact make it "EASIER" to administer, but it does NOT remove the expertise required from the equation.
The fact that SQL Server has been pushed as "easier" then Oracle is a blight that has been inflicted upon us by the marketing teams at Microsoft. Knowing WHY to use something, HOW to use it, and under which circumstances that particular tool is not useful makes all of that "easy" convenience, well....complicated. If the sales teams would stop pushing so hard on the "any idiot with a SQL Server CAL can administer SQL Server", a lot of those misconceptions would go away.
There is a certain amount of complexity built-in to any database deserving of its name. That's after all why the RDBMS model exists (to handle more complex data structures than can be handle through flat data storage systems, like Excel), and until there's some actual breakthrough into REAL AI, someone is actually going to need to have some actual experience to manage data (certainly data over a certain size, etc...)....
Interestingly enough - removing some of the "convenient tools" would also help, so there is something to be said for making the system "hard".
----------------------------------------------------------------------------------
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?
April 28, 2008 at 3:31 pm
The tools used shouldn't make the job harder to do. I agree with the concept of making the tools facilitate the job at hand but not dumb it down.
I have seen so many instances (no pun intended) where SQL Server has been installed by a Windows admin person who is technically competent and can follow the prompts well enough, but then gets stumped beyond that. Things like being asked for a SQL login - 'Well, there was that sa thing during setup, I'll try that.', and then leaving it like that. Annoyingly, there are still off-the-shelf products that do this crap. Then there are backups and other routine maintenance.
To a degree, Microsoft seem to have tried to make it easy enough to install and setup basic maintenance, but people have a habit of not RTFM, so some of the basic but important stuff (e.g., recovery models) doesn't get picked up on. How many posts have we seen on the forums here with "My transaction log just keeps growing. Why? Help!"? (Actually, Steve, that would be an interesting bit of trivia to find out. Well, related, anyway. 😀 )
A lot of people get it installed, it runs OK and the users are happy, so that ends up being the end of it. Until something goes wrong.
So in the end, you still need someone somewhere that knows the ins and outs of the product, whether that is someone specifically paid to do it or someone upskilling to cover it when required.
MARCUS. Why dost thou laugh? It fits not with this hour.
TITUS. Why, I have not another tear to shed;
--Titus Andronicus, William Shakespeare
Viewing 13 posts - 1 through 12 (of 12 total)
You must be logged in to reply to this topic. Login to reply