RE: Performance/Design Advice or DBA vs. Developer

If he doesn't want to use a database, why make him use one. Maybe
he should just create a file somewhere on the server. That way nobody will
blame you.

He has a very shallow understanding of performance.

I'd like him to take a look at one of our systems that has a string
like this at the heart of one of the main tables. The developers couldn't be
bothered to do it "right", so we're stuck with a crippled design because so
much has been built around this mistake that the only feasible way to fix it
would be to rewrite the entire system.

reports from this table will not have to parse the data out by
space-delimiters during execution

this also seems to correspond more towards 3rd Normal Form

I'm concerned about row-chaining on such a long column

Here is the response from one of the developers:

I can maybe be convinced otherwise, but here is my thinking in support of
the "one big field" [varchar2(4000)?] theory:

Our database machines are not storage constrained, nor should they
ever be, therefore, a varchar2(a bunch) field shouldn't be that much of a
hardship. I'm unaware of performance issues that may arise by using a
varchar2 field of this size. Anybody have any info on this?

Our batch loads are hulking processor hogs. When we look for
changes to targets which we will probably do once per target list per load,
we will need to compare an unparsed class config target list to one parsed
out into 5 or 10 or 200 rows -- this is going to be very ugly, loopy,
expensive. We will also need to parse out the individual entries and create
a row for each.

The number of times that we will need to report a given target list
in a parsed format should be small; some may never be displayed. When the
time does come to report a target list, a java or perl (or even owa_pattern)
regular expression replace operation is not all that expensive in terms of
processing.

What do you guys think- anyone have experience with this type of situation?

PS- Environment is Oracle 9.2.0.2 on Sun Solaris; the database is hybrid
OLTP and reporting.

Thanks for sharing,

David B. Wagoner
Database Administrator

--
Please see the official ORACLE-L FAQ: http://www.orafaq.net
--
Author: DENNIS WILLIAMS
INET: DWILLIAMS_at_LIFETOUCH.COM
Fat City Network Services -- 858-538-5051 http://www.fatcity.com
San Diego, California -- Mailing list and web hosting services
---------------------------------------------------------------------
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).