Why are Oracle table/column/index names limited to 30 characters?

Question

I can understand that many years ago there would be this kind of limitation, but nowadays surely this limit could easily be increased. We have naming conventions for objects

Answer 1

The direct answer to the question is that Oracle style is inherited from older ideas in which 30 seemed a lot, and much more would have increased the risk of unpinning the dictionary cache from real memory in typical databases.

In contrast, ODBC namespace comes from a very different place, where data sets are extracted rapidly by parsing a table in an Excel sheet and automatically build database tables with column names taken from sheet table headings. Thinking like that leads you to allowing identifiers that even contain embedded carriage returns, and of course special characters and mixed case. It's a sensible abstraction because it models the way today's data analysts think.

Never mind SQL92, it's ODBC compliance that really matters to today's universal database, and other vendors have addressed this better than Oracle. Even Teradata, for example, which isn't seen by many as a pervasive player, caters for TWO namespaces, with and without the quotes, the former with a 30 char limit, the latter a full ODBC implementation where weird long identifiers are catered for.

Even in the traditional large database arena, 30 characters is often a problem where names are to remain meaningful, consistent and memorable. Once you start to design specialising structures with role-named inheritance you start abbreviating abbreviations, and consistency soon dies, because for example the same root identifier rendered as a table name or a column name will in one case need further abbreviation and in the other not. If real users in significant numbers are invited on to such layers the consequences are very poor usability, and fortunately for any ageing database the main drive now is to separate user from database via object layers and BI tools.

This leaves the database layer to the DBA and the data architect teams, who are perhaps not that bothered. Working out abbreviation schemes is still a job for life, it seems.

That Oracle has not addressed this old limitation perhaps reflects mostly on the fact that it is not (yet) losing much business to its competition when it can't directly port database designs built using longer identifiers.