Database Software

Agree, this will also help in doing cross RDBMS migration from RDBMS where higher limit is available.

i wont go for 90 char limit but yes 60 is good.

regards

Pravin

Yes, sometimes it is a bit short

Or at least give the option for a long name such as for java classes, e.g. JAVASNM view to get the full JAVA_CLASS name from the generated 30 chars abbreviated name  that shows on the *_OBJECTS views.

....Realize this has the potential to break a lot of old applications, so it should probably be explicitly enabled....

"Meaningful" names longer than 30 characters will also introduce a lot of performance issues (among others data dictionary wise)

"32K varchars in tables" option that was introduced in 12c.

Bigger is also not a better method...Ever tried to search in strings, or (piece wise) updates, that big as 32K...?

....Realize this has the potential to break a lot of old applications, so it should probably be explicitly enabled....

"Meaningful" names longer than 30 characters will also introduce a lot of performance issues (among others data dictionary wise)

"32K varchars in tables" option that was introduced in 12c.

Bigger is also not a better method...Ever tried to search in strings, or (piece wise) updates, that big as 32K...?

I'd agree longer is not better....

Longer names are harder to read, especially if you have names 90 characters long that differ by just a few characters.

Also harder to prevent code spilling over to the next line if the names alone almost fill a whole line.

Names need to be clear and concise, and that means keeping the lengths to a sensible limit.

I'd agree longer is not better....

Longer names are harder to read, especially if you have names 90 characters long that differ by just a few characters.

Also harder to prevent code spilling over to the next line if the names alone almost fill a whole line.

Names need to be clear and concise, and that means keeping the lengths to a sensible limit.

Wait long enough and someone will propose case-sensitive object names in Oracle so that they can enjoy Camel Case for "readiblity".

Cheers,
Brian

Does Oracle prepare the Data dictionary for longer names already?

Data Dictionary

Strictly speaking the maximum possible length for a table identifier is already 65 characters.

"SCHEMANAME"."TABLENAME"

schema name can be 30 chars, table name can be 30 chars + 4" + 1.

But I hit the 30 char limitation pretty often. Especially if it comes to nameing conventions for foreign keys and indexes. So I'm all for increasing the length a little bit.

CamelCase of cause is already possible. But luckily it is not used a lot.

Strictly speaking the maximum possible length for a table identifier is already 65 characters.

"SCHEMANAME"."TABLENAME"

schema name can be 30 chars, table name can be 30 chars + 4" + 1.

But I hit the 30 char limitation pretty often. Especially if it comes to nameing conventions for foreign keys and indexes. So I'm all for increasing the length a little bit.

CamelCase of cause is already possible. But luckily it is not used a lot.

Exactly. When I have a name length issue it is with index names.

Wait long enough and someone will propose case-sensitive object names in Oracle so that they can enjoy Camel Case for "readiblity".

Cheers,
Brian

Camel case has been around since at least 8i.

SQL> create table "Table" ( col NUMBER);

Table created.

Elapsed: 00:00:00.09
SQL> create table "tAble" ( col NUMBER);

Table created.

Elapsed: 00:00:00.04
SQL> create table "taBle" ( col NUMBER);

Table created.

Elapsed: 00:00:00.02
SQL> create table "tabLe" ( col NUMBER);

Table created.

Elapsed: 00:00:00.02
SQL> create table "tablE" ( col NUMBER);

Table created.

Elapsed: 00:00:00.03
SQL> select table_name from user_tables where upper(table_name)=upper('TABLE') order by 1;

TABLE_NAME
------------------------------
Table
tAble
taBle
tabLe
tablE

Elapsed: 00:00:00.06

Camel case has been around since at least 8i.

SQL> create table "Table" ( col NUMBER);

Table created.

Elapsed: 00:00:00.09
SQL> create table "tAble" ( col NUMBER);

Table created.

Elapsed: 00:00:00.04
SQL> create table "taBle" ( col NUMBER);

Table created.

Elapsed: 00:00:00.02
SQL> create table "tabLe" ( col NUMBER);

Table created.

Elapsed: 00:00:00.02
SQL> create table "tablE" ( col NUMBER);

Table created.

Elapsed: 00:00:00.03
SQL> select table_name from user_tables where upper(table_name)=upper('TABLE') order by 1;

TABLE_NAME
------------------------------
Table
tAble
taBle
tabLe
tablE

Elapsed: 00:00:00.06

Camel case works since Oracle 4...

(http://www.liberidu.com/blog/2006/10/15/with-double-quotes-almost-everything-goes%E2%80%A6/)

If you want annoy your colleagues start with a object/table name with spaces...

Camel case has been around since at least 8i.

SQL> create table "Table" ( col NUMBER);

Table created.

Elapsed: 00:00:00.09
SQL> create table "tAble" ( col NUMBER);

Table created.

Elapsed: 00:00:00.04
SQL> create table "taBle" ( col NUMBER);

Table created.

Elapsed: 00:00:00.02
SQL> create table "tabLe" ( col NUMBER);

Table created.

Elapsed: 00:00:00.02
SQL> create table "tablE" ( col NUMBER);

Table created.

Elapsed: 00:00:00.03
SQL> select table_name from user_tables where upper(table_name)=upper('TABLE') order by 1;

TABLE_NAME
------------------------------
Table
tAble
taBle
tabLe
tablE

Elapsed: 00:00:00.06

I think we are all aware of the havoc that can be caused by double-quoting identifiers. The concern is that there are probably people who would like this to become the new normal

in times of unlimited lenght of file names

column identifiers should be 60 char at least, better 90 chars.

I run into situation to shorten column names bevause of 30 chars limit quite often.

The problem is, other people often do not know about what was schortened.

in times of unlimited lenght of file names

column identifiers should be 60 char at least, better 90 chars.

I run into situation to shorten column names bevause of 30 chars limit quite often.

The problem is, other people often do not know about what was schortened.

There aren't many words in most languages which have a high length. Since columns resemble attributes of an entity I wonder which real world attribute has such a long name? Maybe you add to much redundant information into the column name?

I think it is different for indexes, since they can span several columns.

I totally agree to leave lenght of column name as is.

sorry, my fault.

I should have written column identifier instead of column names.

May be you're right,

to bypass the limit, just think about meaningfull shortcuts.

I totally agree to leave lenght of column name as is.

sorry, my fault.

I should have written column identifier instead of column names.

May be you're right,

to bypass the limit, just think about meaningfull shortcuts.

No please do not misunderstand me. I voted up.

I just think that for some objects like columns there is a tendency to clutter them with to many naming conventions that all use up the avaible space.

For example a column name like "EMP_HIRE_DATE_BY_MONTH_COLUMN". The only important thing here is "HIRE".

Which in turn makes the code incomprehensible. Which doesn't mean if the length restriction is loosend a little bit, we all might profit.

It is a little different for foreign key contraints (they have a from-to meaning) and also for indexes (they can span several columns).

+1 - increase length.  -1 - abbreviations

In SQL Server, the limit is 128 characters.

When I started using a third party SQL Server application, I was initially taken aback at the 'ridiculous' length of its table and column names.  However, there were no abbreviations, no TLA naming nightmares (for example. DBMS_MGD_ID_UTL, AQ$_NTFN_MSGID_ARRAY) and, when coding, I only had to enter the first few letters then select the table from an IDE provided completion list.

I can't understand why it's taken Oracle Corp. so long to get around to this.

30 char. has always been way too short, resulting in crypt hard-understand table names.

I don't see any problems in increasing this beyond 100 - you just have to apply a sensible naming policy to prevent things getting out of hand.

Thanks everybody for your contribution!

This idea has been implemented and will be coming in the next release.

Thanks everybody for your contribution!

This idea has been implemented and will be coming in the next release.

What length have you chosen?

The new limit will be 128 characters.

The new limit will be 128 characters.

There are estimates about which release will change the limits in DDL (I've seen that the deeper tables names are already 128 char)?

Thank you in advance for the kind reply.

yes this should be done.

***Moderator action (Timo): remainder: User please make more substantial  comments and refrain from 'me too' like comments. If you have no substantial comment, a simple vote will do.***

As said: Like creating filenames, why create a file if you can use the contents as a name?

+1 from me. We are no longer living in 1992 ... please increase it.

***Moderator action (Gerald): Reminder: User please make more substantial  comments and refrain from 'me too' like comments. If you have no substantial comment, a simple vote will do.***

I would vote for YES.

sometimes, I have to create/restore backup tables with date and time stamp.

xxxx_20160830_145450.

With date/time stamp it will be 15 bytes long, with original table names added, it will easily over 30 bytes long.

(It is better to keep the original table/view/procedure/package names as prefix when creating backup copies)

Thanks everybody for your contribution!

This idea has been implemented and will be coming in the next release.

Hi Gerald,

Any approximate time frame for next release?

Thanks.

Hi Gerald,

Any approximate time frame for next release?

Thanks.

It is available in Oracle DB 12.2.

And 12.2 is out already, however only as a cloud version yet. So if you decide to move your database to the cloud, then you would be able to profit from the longer identifieres (I have not tested that!).

There is currently no official statement from Oracle as to when all normal customers (EE, SE2, etc.) will get the new DB version. My guess would be next year. But I might be wrong and it will take even longer....

I would Vote YES as it will help help in having proper naming conventions as few systems with which we are integrating have complex naming conventions.

If this limit in oracle increased to 50 or 60, that would help