If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

No, everyone gets to set & ignore the "standards" of their own choosing.

You can lead some folks to knowledge, but you can not make them think.
The average person thinks he's above average!
For most folks, they don't know, what they don't know.
Good judgement comes from experience. Experience comes from bad judgement.

I am really a non-DB guy. Well, in Java and other languages, there are naming conventions for variables and functions. Like in Java, you follow this convention for naming a variable.

String firstName and NOT String FirstName

So, my question is simple after this example, that is there any "Naming Convention" in Oracle 9i for Table Names and Column Names?

One point to note is that Oracle prefers to be case-insensitive about column names. Therefore it does not differentiate between firstName and FirstName, and in fact that column would appear as FIRSTNAME in the data dictionary. For that reason, it is very common practice (almost a universal "standard") to use underscores to separate the words in table and column names: FIRST_NAME.

(Actually it is possible to make Oracle column names case-sensitive, by enclosing them in double quotes: "FirstName". But then the column can only be referenced in double quotes, which is a huge pain. So please, don't ever define table or column names that way!)

Another programming practice to avoid bringing to table and column names is Hungarian notation. A table of employees should be called EMPLOYEES not tblEmployees (which would look like TBLEMPLOYEES in the data dictionary); a column for the employee's first name should be called FIRST_NAME not strFirstName. We know from context that EMPLOYEES is a table! We can see using "DESC employees" that FIRST_NAME is VARCHAR2(30) (e.g.) - we don't want or need a "str" prefix!

Yet another source of frustration is when the "same" column has radically different names in different tables, leadng to SQL like: