add comments for all database objects like for tables and table columns

Torsten Kleiber

Please add optional comment fields to all database objects like for tables and table columns, for example for users, packages, functions, function parameters and so on.

Please fill this comments for all oracle objects.

It will be a lot easier to document the purpose of the objects for the developers and internal and external auditors.

GregV

For programs usually you add the comments within the source code. But it may be useful for some other objects I agree.

Sven W.

Good idea. I think this has been suggested before. At least I remember it for schemas, but also for indexes.

Which objects do you specifically think of, where you miss the comment?

A quick search shows that the Idea for adding comments for indexes is now "under review" and that an enhancement requests exists. Which is good.

Thank you for your contribution. This is an excellent idea and has been accepted for review by Oracle Development.We have created an Enhancement Request in MOS: ER 23527965 - INTRODUCE COMMENTS FOR INDEXES

For procedures, functions and packages I do not see the need. As GregV mentioned, usually we put extended comments directly in the code. Also parameters are not database objects. So they wouldn#t be covered by the suggestion.

Torsten Kleiber

Good idea. I think this has been suggested before. At least I remember it for schemas, but also for indexes.

Which objects do you specifically think of, where you miss the comment?

A quick search shows that the Idea for adding comments for indexes is now "under review" and that an enhancement requests exists. Which is good.

Thank you for your contribution. This is an excellent idea and has been accepted for review by Oracle Development.We have created an Enhancement Request in MOS: ER 23527965 - INTRODUCE COMMENTS FOR INDEXES

For procedures, functions and packages I do not see the need. As GregV mentioned, usually we put extended comments directly in the code. Also parameters are not database objects. So they wouldn#t be covered by the suggestion.

I think for all object for document the purpose:

For auditors I see repeating request on users, roles, database links.

For developers and dba's all the other + the above

And if you you have a 20 year growing database, nobody knows where to find this information.

Sven W.

I think for all object for document the purpose:

For auditors I see repeating request on users, roles, database links.

For developers and dba's all the other + the above

And if you you have a 20 year growing database, nobody knows where to find this information.

Database links is a good idea. I didn't think of them so far. Decided to vote up now.

As a side note: For general documentation purposes: try the SQL developer "Generate DB doc" functionality.

Rightclick on a connection and choose the entry.

BrunoVroman

I vote up because this would be a "nice to have" but frankly I think that the last time I created a comment for a table or for a column was close to 20 years ago... For PL/SQL code I think that instead of creating a comment of this form it is better and important to put a header in the code itself (this gives the opportunity to put much more info than a simple "comment": object, creation time, last modification time, modifications, dependencies, explanations...

I like the "Generate DB Doc" mentioned by Sven ;-)

GregV

I vote up because this would be a "nice to have" but frankly I think that the last time I created a comment for a table or for a column was close to 20 years ago... For PL/SQL code I think that instead of creating a comment of this form it is better and important to put a header in the code itself (this gives the opportunity to put much more info than a simple "comment": object, creation time, last modification time, modifications, dependencies, explanations...

I like the "Generate DB Doc" mentioned by Sven ;-)

Bruno.Vroman wrote:I think that the last time I created a comment for a table or for a column was close to 20 years ago...

Seriously ?

I systematically add comments for all tables and their columns. And 20 years ago is more a less the time when the company that made the crappy third-party application I'm tortured working with created it. In 20 years they never thought of adding a single comment in any of the tables or columns. But that's nothing compared to storing dates in varchar2, having no fks at all, storing blanks instead of nulls....

BrunoVroman

Bruno.Vroman wrote:I think that the last time I created a comment for a table or for a column was close to 20 years ago...

Seriously ?

I systematically add comments for all tables and their columns. And 20 years ago is more a less the time when the company that made the crappy third-party application I'm tortured working with created it. In 20 years they never thought of adding a single comment in any of the tables or columns. But that's nothing compared to storing dates in varchar2, having no fks at all, storing blanks instead of nulls....

<storing dates in varchar2, having no fks at all, storing blanks instead of nulls>

Ha ha, except for "blanks instead of nulls" the situation is identical with our main application (also: no PK of course, I have even a (very) large table without any index, and several tables without any column defined as 'not null'...

They want to stay "database agnostic" so the only datatypes they want to use are VARCHAR2 and NUMBER... and for example they store dates as 'YYYYMMDDHH24MISS0000' (always four zeroes as we don't use sub-second, but this has been designed 'in case of') (still, when they need to compute a difference between "dates_in_strings", they call a function that... calls "to_date" Hmmmmm

About comments I have also to say that I haven't designed a database for about 20 years either...

Best regards,

Bruno