| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> Re: Criteria for handoff from development
the manager is wrong -- as a model will NOT tell you where additional indexes could be helpful. While a look at the queries could.
What I've always done is sit with the architect and go over each entity and see if it should be denormalized for performance (it's all well and good to have a separate table for addresses for a customer, but it still might be worthwhile to keep the primary address within the customer table itself).
Check that all foreign keys are properly defined, you'll need to know them to build the indices so you don't hang on updates.
Hm.... look for common sense changes. As an example, at one place we ended up with this insane set of tables to define "address" because an address could be a street address, email address, phone number, etc etc. We had "address_element", "address_element_format", "address_element_in_address" etc etc
at which point I just said NO.
that should get you started
Rachel
--- DENNIS WILLIAMS <DWILLIAMS_at_LIFETOUCH.COM> wrote:
> Can anyone provide some criteria of what you look for when a data
> model is
> handed off from production? We are starting a large development
> project and
> I lobbied management to hire a data architect. As they have talked to
> these
> people, they are getting statements such as "and then the DBA will
> check out
> the data model to make sure there won't be any performance problems".
> I am
> concerned about what will be expected of me and wondered how other
> DBAs
> handle this situation. What do you look for in a model in terms of
> making
> sure the performance will be good? I said that I could look at the
> queries
> that would be run to see how many tables would need to be joined to
> retrieve
> the data, but the manager replied that a good DBA wouldn't need to
> see the
> queries, should just be able to look at the model. Up until this
> point, our
> client-server design tools have tended to protect the developers from
> doing
> dumb stuff, but now in the Java world some of those safeguards.
>
> Dennis Williams
> DBA
> Lifetouch, Inc.
> dwilliams_at_lifetouch.com
>
> --
> Please see the official ORACLE-L FAQ: http://www.orafaq.com
> --
> Author: DENNIS WILLIAMS
> INET: DWILLIAMS_at_LIFETOUCH.COM
>
> Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
> San Diego, California -- Public Internet access / Mailing
> Lists
> --------------------------------------------------------------------
> To REMOVE yourself from this mailing list, send an E-Mail message
> to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
> the message BODY, include a line containing: UNSUB ORACLE-L
> (or the name of mailing list you want to be removed from). You may
> also send the HELP command for other information (like subscribing).
-- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Rachel Carmichael INET: wisernet100_at_yahoo.com Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051 San Diego, California -- Public Internet access / Mailing Lists -------------------------------------------------------------------- To REMOVE yourself from this mailing list, send an E-Mail message to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).Received on Fri Jan 04 2002 - 18:09:57 CST
 |
 |