Re: Thoughts on comments
- From: z b <zimsbait@xxxxxxxxx>
- To: andy@xxxxxxxxxxxxxxx
- Date: Fri, 22 Mar 2013 10:45:49 -0400
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@xxxxxxxxxxxxxxx> wrote:
> On Fri, Mar 22, 2013 at 10:14 AM, Mark W. Farnham <mwf@xxxxxxxx> 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
>
>
> --
> //www.freelists.org/webpage/oracle-l
>
>
--
//www.freelists.org/webpage/oracle-l
Other related posts:
