Re: consolidation of multiple rows

Michael Austin wrote:
> 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. 

>>  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.

These DBA's work in an entirely different environment. Their managers understand the real meat is in ability to do the job and not just hold a piece of paper.

Companies who only care about a certification have no idea what they really need. Rather than getting someone to help them hire the correct person, they just say you need a certification. Personally, I wouldn't work for such a company.

> 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.
>

That's what happens when you use head hunters who have no idea what they're doing (which is most of them). Same with hiring managers. You need to find the person who makes the decisions and talk to him/her directly.

> 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.
>

No, people move on. But the people who replace them are just as qualified and knowledgeable. Big companies can't afford anyone less.

Picture a major airline who couldn't access their reservations system quickly, a shipping company who can't track packages reliably, or an automobile manufacturer who can't manage their parts inventory, all because performance is so bad.

Neither is good for long term viability of the company.

> 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.
>
>

Agreed, but if the job was done properly in the first place, that isn't as much of a problem. From what I've seen as a bigger problem over the years is the changing needs for the database. Different information required, different reporting, etc. Eventually, the creep becomes so severe that the current database has little or no resemblance to the one designed 20 years ago. But there are millions of lines of COBOL (or whatever) code accessing it.

You're correct - it costs a fortune to make the changes. But eventually they often need to do a complete rewrite. And that keeps programmers busy.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex_at_attglobal.net
==================