Re:RE: Rant-Rant
Dick, It helps that I've worked on a site like this one before. And that I suddenly realized (must have been the alcohol over the weekend letting my subconscious work) that I did NOT have to give the %^&*( developer individual tables for EACH type of product we wanted to sell but could do as I wanted (a "merchandise" table) and give him views that cut things the way he wanted to see them. Joy Rachel --- [EMAIL PROTECTED] wrote: > Rachel, > > Commen sense is the best guide to data modeling. That and a > white board > with a pile of post-it notes. Unless you can afford one of thise > mega$ data > modeling tools that takes half a lifetime to master. > > Dick Goulet > KISS :O) > Reply Separator > Author: Rachel Carmichael <[EMAIL PROTECTED]> > Date: 7/22/2002 11:23 AM > > >The only problem with your idea that I see is that a typical > >organization > >will only keep one (or so) DBA on staff per project - they rarely > have > > > > excuse me while I wipe the Diet Coke off the screen that I spit out > when I read this. One DBA per project? Oh God that would be a luxury > beyond belief. > > As I type this I am the DBA for: > > a new data mart/data warehouse project > a new content management system project > a new ecommerce project > the existing "universal login" project AND the replacement project > the existing asset management application > the existing "community" site (bulletin boards) > > and anything else that needs a DBA ... and I am it, ain't no other > DBAs > around .. > > oh yeah, I'm the data architect and data modeler on half these as > well... which is REALLY funny as I have almost zero data modeling > experience, other than "common sense" > > > --- "Mercadante, Thomas F" <[EMAIL PROTECTED]> wrote: > > OMG! A Socialist in the group! > > > > "I believe that if we think about these things in a way that we ask > > > ourselves how can I maximize the potential of this person in our > > organization, pay him/her a fair wage for what they can do, and > free > > up my > > time to address the really gnarly stuff we can help our entire > > society > > better transition to the information era and not marginalize a > bunch > > of > > great people in the process." > > > > The only problem with your idea that I see is that a typical > > organization > > will only keep one (or so) DBA on staff per project - they rarely > > have the > > cash for multiple people. So a DBA ends up getting called upon do > > cross the > > boundary between very technical stuff as part of the SA group and > > data > > access/design with the applications group. Lots of room in between > > here for > > talented people. > > > > Tom Mercadante > > Oracle Certified Professional > > > > > > -Original Message- > > Sent: Monday, July 22, 2002 1:23 PM > > To: Multiple recipients of list ORACLE-L > > > > > > I have been reading this list for the past several months as I > > prepare to > > move my universe of databases from 7.3 to 9 (probably 9) and I have > a > > rant > > of my own. > > > > It seems that the implicit expectation is that every DBA should be > or > > > > should aspire to be a Master Technical DBA. > > I have a slightly different take on the situation. It is a little > > convoluted but I believe that the DBA world needs some additional > job > > > > classifications. In a decent sized organization, the day to day > > management > > functions should be accomplished by an Admin DBA who might be > someone > > who > > was perfectly happy spending his/her working career operating a > > precision > > milling machine at Boeing. Since the machinist jobs are going away, > I > > see > > no reason why a competent machinist could not become a competent > > admin DBA. > > Such a person is not suited by aptitude or disposition to become a > > Master > > Technical DBA, but would do a great job at the admin level. > > > > I'll extend the analogy a little more: the manufacturing > organization > > does > > not expect the machinist to program the machine. They either have > on > > staff > > or bring in a numerical control programming specialist. Similarly, > > the > > Admin DBA should know which tasks he/she can perform and which > tasks > > should > > be kicked up or out to the next level. > > > > So maybe some of the energy spent on this list about relevance of > the > > OCP > > and discussing qualifications of DBAs (against an unspecified > > standard) > > could be spent defining organizational strategies for getting the > > best use > > out of human capital represented by "Admin DBAs" and pricing the > > skill set > > appropriately. The worst possible thing is to get an Admin DBA into > a > > > > Technical DBA position. > > > > I think the key breakthrough is the notion that there is a DBA > track > > that > > does not inevitably lead to Master Technical DBA. That is why I use > > the > > machinist analogy: somebody who is sa
Re:RE: Rant-Rant
Rachel, Commen sense is the best guide to data modeling. That and a white board with a pile of post-it notes. Unless you can afford one of thise mega$ data modeling tools that takes half a lifetime to master. Dick Goulet KISS :O) Reply Separator Author: Rachel Carmichael <[EMAIL PROTECTED]> Date: 7/22/2002 11:23 AM >The only problem with your idea that I see is that a typical >organization >will only keep one (or so) DBA on staff per project - they rarely have excuse me while I wipe the Diet Coke off the screen that I spit out when I read this. One DBA per project? Oh God that would be a luxury beyond belief. As I type this I am the DBA for: a new data mart/data warehouse project a new content management system project a new ecommerce project the existing "universal login" project AND the replacement project the existing asset management application the existing "community" site (bulletin boards) and anything else that needs a DBA ... and I am it, ain't no other DBAs around .. oh yeah, I'm the data architect and data modeler on half these as well... which is REALLY funny as I have almost zero data modeling experience, other than "common sense" --- "Mercadante, Thomas F" <[EMAIL PROTECTED]> wrote: > OMG! A Socialist in the group! > > "I believe that if we think about these things in a way that we ask > ourselves how can I maximize the potential of this person in our > organization, pay him/her a fair wage for what they can do, and free > up my > time to address the really gnarly stuff we can help our entire > society > better transition to the information era and not marginalize a bunch > of > great people in the process." > > The only problem with your idea that I see is that a typical > organization > will only keep one (or so) DBA on staff per project - they rarely > have the > cash for multiple people. So a DBA ends up getting called upon do > cross the > boundary between very technical stuff as part of the SA group and > data > access/design with the applications group. Lots of room in between > here for > talented people. > > Tom Mercadante > Oracle Certified Professional > > > -Original Message- > Sent: Monday, July 22, 2002 1:23 PM > To: Multiple recipients of list ORACLE-L > > > I have been reading this list for the past several months as I > prepare to > move my universe of databases from 7.3 to 9 (probably 9) and I have a > rant > of my own. > > It seems that the implicit expectation is that every DBA should be or > > should aspire to be a Master Technical DBA. > I have a slightly different take on the situation. It is a little > convoluted but I believe that the DBA world needs some additional job > > classifications. In a decent sized organization, the day to day > management > functions should be accomplished by an Admin DBA who might be someone > who > was perfectly happy spending his/her working career operating a > precision > milling machine at Boeing. Since the machinist jobs are going away, I > see > no reason why a competent machinist could not become a competent > admin DBA. > Such a person is not suited by aptitude or disposition to become a > Master > Technical DBA, but would do a great job at the admin level. > > I'll extend the analogy a little more: the manufacturing organization > does > not expect the machinist to program the machine. They either have on > staff > or bring in a numerical control programming specialist. Similarly, > the > Admin DBA should know which tasks he/she can perform and which tasks > should > be kicked up or out to the next level. > > So maybe some of the energy spent on this list about relevance of the > OCP > and discussing qualifications of DBAs (against an unspecified > standard) > could be spent defining organizational strategies for getting the > best use > out of human capital represented by "Admin DBAs" and pricing the > skill set > appropriately. The worst possible thing is to get an Admin DBA into a > > Technical DBA position. > > I think the key breakthrough is the notion that there is a DBA track > that > does not inevitably lead to Master Technical DBA. That is why I use > the > machinist analogy: somebody who is satisfied with a career spending > 25 > years doing essentially the same thing. If you are into Myers-Briggs > type > indicator, I think the personality dimension is SJ and roughly 25% of > the > population fits this profile. > > I believe that if we think about these things in a way that we ask > ourselves how can I maximize the potential of this person in our > organization, pay him/her a fair wage for what they can do, and free > up my > time to address the really gnarly stuff we can help our entire > society > better transition to the information era and not marginalize a bunch > of > great people in the process. (Sez the man operating a three person > software company). > > Re: Hotbackups. > In the
