Re: Thoughts on comments

From: z b <zimsbait_at_gmail.com>
Date: Fri, 22 Mar 2013 10:45:49 -0400
Message-ID: <CAAKk1mhY-bNOF+PQe2Ar7hdmPkKbKdJXQT_4ChBBH2gNFxiKMw_at_mail.gmail.com>

Thanks for the Friday morning of enlightenment!

I agree with Kellyn. I'm a big fan of doing what's right and what makes sense. I don't think storing the entire data dictionary inside the database is the best option. I can see the value for developers that are writing ad-hoc stuff, but those folks (even with comments) should be on the shortest leash and managed correctly in DBRM. (different rant, sorry). Though I may be wrong, I think you should know what you're looking for before you go on a data hunting expedition in a 100TB warehouse.

Excellent input from the community, as always.

On Fri, Mar 22, 2013 at 10:23 AM, Andy Klock <andy_at_oracledepot.com> wrote:
> On Fri, Mar 22, 2013 at 10:14 AM, Mark W. Farnham <mwf_at_rsiz.com> wrote:
>> Hmm. Kevlar makes an excellent point. Learning mode on: I think I'm
>> revising
>> my notion they should flow from the data model to the database. Okay, IF
>> you're going to have comments in the database you'll need to make sure it
>> is
>> a situation that cannot snowball into a performance problem (See Kevlar
>> post), AND, they should come from the data model if you're going to have
>> them.
>>
>
>
> I was hoping that Kellyn was going to mention her case for comments. I've
> always been a fan of comments, but was briefly deterred when she described
> them being an issue in some cases. Apart from additional space, I thought
> they were benign.
>
> As for a side benefit, I've been known to use table comments (on versions
> prior to 11g where dbms_shared_pool.purge doesn't exist) when I have to
> invalidate a cursor to force a new hard parse. If you are on a database
> with a comment "fast=true", that might very well have been me.
>
> Andy
>
>
> --
> http://www.freelists.org/webpage/oracle-l
>
>

--
http://www.freelists.org/webpage/oracle-l

Received on Fri Mar 22 2013 - 15:45:49 CET