Re: consolidation of multiple rows
Date: Sun, 09 Mar 2008 21:20:12 GMT
Message-ID: <gwYAj.13417$xq2.4282@newssvr21.news.prodigy.net>
Jerry Stuckle wrote:
> Michael Austin wrote:
>> Jerry Stuckle wrote: >>> DA Morgan wrote: >>>> Jerry Stuckle wrote: >>>>> DA Morgan wrote: >>>>>> Jerry Stuckle wrote: >>>>>>> DA Morgan wrote: >>>>>>>>>> If you know the names Date and Codd you should know who you are >>>>>>>>>> addressing: Joe Celko. >>>>>>>>> >>>>>>>>> Not a name I am familiar with. >>>>>>>> >>>>>>>> Says much about your attitude toward our profession. >>>>>>>> >>>>>>>> Enlighten yourself: >>>>>>>> http://en.wikipedia.org/wiki/Joe_Celko >>>>>>>> http://www.dbmsmag.com/artin301.html#A000009 >>>>>>>> http://www.google.com/search?hl=en&q=%22Wikipedia%22+and+%22Joe+Celko%22&btnG=Google+Search >>>>>>>> >>>>>>> >>>>>>> Not necessarily. There are a lot of top notch programmers and >>>>>>> DBA's who have never heard of Joe Celko. >>>>>> >>>>>> Well right now I can only name one. <g> >>>>>> >>>>>> Of course you are correct. There are top notch programmers that >>>>>> don't know who Chris Date is. There are top notch programmers >>>>>> that don't know who Dennis Ritchie and Ray Boyce are either no >>>>>> doubt. >>>>>> >>>>>> Though I suspect you could put the names of those "top notch" >>>>>> programmers on a 3x5 card. >>>>> >>>>> Quite incorrect. Right off the top of my head I can probably name >>>>> a dozen I know personally who haven't heard of him. He's well >>>>> known in some circles, but definitely not all. >>>> >>>> The operative phrase here is "top notch." If they ever took even a >>>> basic >>>> class on normalization they could not have missed the name Boyce. If >>>> they learned more in C than "Hello World" they'd know who Dennis is. >>> >>> Not necessarily. A lot of great DBA's know normalization but don't >>> know Boyce. And these are DBA's who manage databases in the >>> hundreds of terabyte range, running sometimes tens of thousands of >>> operations a second. They learned normalization techniques and maybe >>> even heard of Boyce and Codd. But they have no idea who they were. >>> >>> And while they were famous 20 years ago, a lot of people who have >>> learned C in the last 10 years or more have never heard of either >>> Kernighan or Ritchie. >>> >> >> Unfortunately I know far to many "so-called" DBA's who "manage" 250+TB >> databases or OLTP databases that do thousands of txn/minute that have >> no clue about normalization or database design or the nuances of SQL >> programming. Managing databases, designing databases and writing SQL >> are really the three sides of the same coin... (yes, a coin is >> 3-dimensional) Each is necessary, but you can **do** one without >> completely knowing and understanding the other. (Since a coin is an >> inanimate object does it *know* it has 3 sides?) It is helpful if you >> have some understanding of the each, but in reality it is not >> necessary. Sadly we are the ones who answer a lot of SQL howto >> questions in CDM,CDOS and MPSP from those who call themselves DBA's >> and may have heard the names of these "legends of technology". >>
>
> I'm not talking thousands of transactions a minute. I'm talking TENS OF
> THOUSANDS ever SECOND. A much higher order of magnitude than you have.
Sorry to disappoint you, this was an example not actual - even a close proximity would be a trade secret.
> To do this successfully, you need to be a great DBA - and these are.
> They have to be to be in the business and companies (mostly Fortune 500)
> they are in. And they have to be able to design databases well - and
> they need to know when to break the normalization rules for performance
> reasons.
>
> But these people don't ask questions. The know the answers already.
> And, if they don't, no one does.
>
> To be a fair DBA you don't need to know everything. But to be a great
> DBA, you've GOT to understand the design, coding and administration of
> databases. Someone may know one part really well. But that doesn't
> make him a great DBA.
>
>
>> The other really sad part is that they were hired because they were >> "certified". >>
>
> None of these are "certified", AFAIK. They were hired for their
> knowledge, not because of a piece of paper. But then they were doing it
> long before certifications were around.
You- and the "great DBA's", my friend, have been fortunate. Recently (last 5-7 years) there are a lot of folks like me who couldn't get a job even as a "contractor" if they tried because we were not "certified". 10-15years experience - yes. Multi-platform, multi-db-engine - yes. Fixed major performance problems on business or mission critical databases for many name-brand F500 companies - yes. But again - more recently - because we did not have that certificate - were passed over or not even considered usually because the certified "DBA" was fresh out of school (term used very loosely) with "certified" behind his/her name and hourly rates at or near the poverty level.
I have had head-hunters hang up on me when they ask about certification. At this point there is no way to talk to the hiring manager. No way to state your case or demonstrate your abilities. But, such is the IT hiring business of today.
Back to our discussion of what it takes to be a great DBA.
Granted, you should be able to do all of the things you stated, but the sad reality in business is that *usually* the people who initially designed that very fast, properly normalized (the balance of when to normalize/de-normalize you indicated), properly sized, properly distributed (physical storage DOES matter) database are not the ones having to maintain it due separation of duties being spouted about by Sarb-Ox auditors everywhere.
I would consider a great DBA to be one that can walk into any shop and take whatever is thrown at them including make current db perform better - keeping in mind that NO amount of physical, memory, sql, index tuning will EVER completely overcome a poor logical design. And the latter is usually connected to some COTS package and there is no way to change it on the production application without $MM in cost over-runs. It can be mitigated, but only to a point. Sometimes starting from scratch is the only way to achieve the required performance. Received on Sun Mar 09 2008 - 16:20:12 CDT