April 10, 2015 at 11:50 pm
Comments posted to this topic are about the item Don't exaggerate the difficulties of the RDBMS
Best wishes,
Phil Factor
April 11, 2015 at 4:51 am
Excellent! Couldn't agree more.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
April 11, 2015 at 5:40 pm
Great article and analogies. One of the first things that they teach you in pottery is "centering". Your pot will fail on the wheel unless you are centered properly. This is true of many disciplines.
I agree that many of us are too hard on the beginners of the forums. I had to learn normalization after doing lots of flat tables. Worse I had to teach others normalization who thought the whole concept was a horrible idea. It made things so complex and isn't simpler always better. What finally won the day was getting across the idea that trying to keep the database design in a head was a mistake. Your head, my head, or any group of heads. That and the demonstrations that showed the advantages that one way was better than the other. Not only that it was better but why it was better. I tend to ask, "In what way is this better? Better for what?"
Over the years I have learned so much from these forums. Even after 4 decades in IT I still learn and expect that there will always be new things to learn. I recommend these forums to folks all the time.
ATBCharles Kincaid
April 13, 2015 at 5:57 am
I have certainly suffered from the temptation to embellish the stuff I do with computers and programs and databases into a somewhat more "mystical" realm.
I, however, have to agree with Phil's comment...and for a different reason. Many of the people in the IT industry have worked to keep their upper echelons amazed at the dark magic involved in utilizing computers and databases and the various solutions they provide. What that has unfortunately done is make an opening for the slick salespeople from an army of vendors who promise that "their" new product will de-mystify the power of computers and provide a solution to their complicated needs that will all but sing and dance. Of course, it often doesn't turn out that way. Worse, the-powers-that-be think they have figured out our "game" and have decided that the combination of expensive platforms and packages from the vendors coupled with easily-replaceable "clerical staff" is all that is needed to build and maintain sophisticated applications.
When IT professionals learn to talk plainly with non-IT management and help them to understand what is needed and how its done, we can become partners with the people who make the decisions and show them the value of the asset(s) that they employ and the power of the technology that already resides within the walls of their company.
April 13, 2015 at 6:50 am
I agree with you on a theoretical point on view. But I feel, the reality is, unfortunately, different.
without recriminations
Most of time this does not occurs, but it's not always the case (position wise)
as long as you clear up afterwards
Once code committed, it become part of the solution and it's a waste of time (from management point of view) to refactor. It works, and they say "why do more in the immediate"?
the only downside is having to feign joy and pleasure
and the same when it crash, have issues and being called late or during the night for something that could have been fixed before but you're powerless to do so (hence my work contracts never stipulate 24/7 availability. Been there, done that, hated that)
Finally, through out my career, only one person really took some time understanding database concept, ask questions, look what I've done and how I've done it, and that person became outstanding. Being able to judge concepts between code & database & business needs made him a critical resource. I was able to let him take his own decision without having to check twice. Some took a bit of time to understand with positive results but not enough to let them take important database decision by their own (asking "why" and take time to at least listen positive and negative outcome of the choice they made). Almost all other fall into the category "I'm done learning" or "get it out my plate" style.
Weak development processes (if any), lack of willingness from the individual (and corporate) for learning / training, weak testing, unrealistic developer - DBA ratio (if any DBA at all), ferociously product competitions in the market put us "there".
I look forward the day that (what you wrote) will happen for everyone.
My 2 cents
April 13, 2015 at 7:21 am
Spot on. Five years ago I didn't know squat about SQL Server, though long before I had taken the time to learn and understand the basics of normalization, at least up through 3rd Normal Form (I can do higher, but I always have to sit down and review them for some reason - mental block or something).
I joke around that I go to work, play around with SQL in my own little sandbox, and sometimes useful stuff pops out. It may not be "perfect" (a.k.a. the gospel according to some guy with a blog about databases or C#) but it gets the job done well enough for my environment.
Which brings up the question of scale. Not everyone develops for a multi-tier enterprise environment. There are very good techniques to implement when designing solutions for that kind of environment which are Rube Goldberg-esque overkill for smaller projects. Yet all too often on the web I get the opposite impression.
Design patterns for example. It's the difference between saying "if you're going to include a bay window, here's how to go about designing it" and "Thou Shalt Have A Bay Window In Every House." I see too much of the latter and not enough of the former.
Musicians learn the fundamentals of reading music and playing whatever instrument catches their interest. They hone their craft through practice. But they make art when they just start playing.
____________
Just my $0.02 from over here in the cheap seats of the peanut gallery - please adjust for inflation and/or your local currency.
April 17, 2015 at 1:21 am
Once again I find myself mentoring someone new to software development. He is very enthusiastic and appears to have a natural affinity to the work. The last thing I want to do is pretend that any of this is difficult. Difficult to get right: yes. Difficult to do: no. Caution is good but fear is not.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
April 17, 2015 at 12:48 pm
We need to be careful that we don't underestimate the difficulty simply because we are good at it, and presumably comes more naturally to us. I used to think that database design was easy and that anyone in IT can understand it. Over the years I've seen how difficult it can be to some people. This is true of any skill. I made the transition to BI and the new concepts fairly easily, but some can't do that. For me, learning German is easy. Others can't grasp the word order changes. For others, dancing is easy. For me that's not true. Don't underestimate your own abilities in this regard.
Viewing 8 posts - 1 through 7 (of 7 total)
You must be logged in to reply to this topic. Login to reply