Just to be clear, the limit on object names in Oracle is 30 characters, not 32 as mentioned in a couple of different places (someone else made the point but didn’t specifically refute the original assertion).

I think we are on the same page on most of your points though we would probably have minor disagreements on specifics.

As to schooling, I have found the same, most schools that I have investigated don’t have a very comprehensive database side of things until you get into the graduate level courses. Just about every job out there is data driven and for those that do pure programming, there is still some level of persistent data (usually in the form of config files or something).

chet

You misunderstand. The alias is not used as the table name but as a standard identifier for field names used as foreign keys. In the ideal world we would use full table names for fields but ORACLE impose a 30 char limit and so the alias approach is the way to go.

It does not increase the learning curve and makes the FK fields stand out when you look at a field list as they are of the form PKG_PRD_ID.

In fact a list of alias and table names is available so it makes reference very easy and we also have copious model diagrams and an excellent modelling tool.

Well each to their own I guess but when you go from 10 table DB’s to 261 at the last count you start to appreciate how those initial standards pay off.

PACKAGE_PRODUCTS – PKG_PRD
BOOKING_PACKAGES – BKG_PKG

I’d like to point out two issues with the above. 1) This is not intuitive for newer people working on your db. You are adding in an unnecessary learning curve, which, despite a persons skills, can present a considerable road block to “getting things done”. How much more difficult is it to type out 6 more characters, in each object name? 2) Please avoid UPPER CASE object names. Not only does it tend to make reading complex queries or scanning a high number of db objects more difficult, it also can cause confusion in case sensitive db’s (e.g. Postgres). Rather, I advocate creating db objects in all lower case, while allowing mixed case of those object names within queries. The advantages you’ll have are: easy readability of objects in queries, easy portability/usage in case sensitive db’s, and scanning db objects in a visual db tool won’t be nearly as difficult as it would be if all objects were UPPER CASE.

Sounds like they need to be coerced into a hierarchical DB structure right? Well, that’s what I did, until a few months later when my colleague realised that no one was changing this info, and it was really just adding unnecessary complexity and latency.

We moved the hierarchy into the code itself, where it’s better-documented, checked into source control, and much faster.

Also, the problem is, you have to write a program/procedure outside the database language to extract useful information from the comma separated list items (the list items could separated in other ways). Say you were recording sales of pies, your non normalized table might be:

Day Sales
Mon Apple 2, Blackberry 2, Cherry 3
Tue Blackberry 2, Apple 2, Cherry 3
Wed Apple 1, Blackberry 2, Apple 1, Cherry 3

The sales for each day are the same, but you can not easily tell. How would you count Apple sales each day or in total? (Partial) Normalizing might give:

Day Product Qty
Mon Apple 2
Mon Blackberry 2
Mon Cherry 3
Tue Apple 2
Tue Blackberry 2
Tue Cherry 3
Wed Apple 2
Wed Blackberry 2
Wed Cherry 3

Using something like:
SELECT Product, COUNT(Qty) AS TotalQty
FROM DailyProductSales
GROUP BY Product ;

Giving:

Product TotalQty
Apple 6
Blackberry 6
Cherry 9

If the data is a string that happens to have commas then it is ok. It is when the field is being used to represent a sequence of values that would otherwise occupy a seperate table that is foreign keyed to the table in which you have put the csv values in.

Example

Table of screen sizes and screen types (field:value)

Type:Plasma size:32,37,42,50,60 resolution 766×355,766×512…
Type:LCD size 28,32,37,40,42,47,50 Resolution 1024×768,1280,960…

Should be a table for screen type

ID Type
1 Plasma
2 LCD

and a table for size

ID SCREEN Size Resolution
1 1 32 766×355
2 1 37 766×512
3 1 42 ..
..
..
n 2 28 1024×768

Like the list a lot. Kind of putting it into words for how we do it here.

As part of the DB design we describe tables (within 30 chars) as best we can and also create an alias to the table (this is just a recorded alias in the modelling tool). We then use this alias for all foreign key references.

Example

BOOKINGS – BKG
BOOKING_ITEMS – BIT

So in BOOKING_ITEMS we have a FK to bookings BKG_ID. If you follow this approach you then get very readable SQL

..
from
bookings bkg,
booking_items bit
where
bit.bkg_id = bkg.id
..

You also keep the foreign key names short which allows the 30 char limit not to be exceeded. The alias is either 3 chars or 7 (2 lots of 3 with an _ between)

PACKAGE_PRODUCTS – PKG_PRD
BOOKING_PACKAGES – BKG_PKG

etc.

You can extend it to FK naming so

BOOKING_ITEMS.BKG_ID would have a FK name of BIT_BKG_FK

any indexes for the FK have an I appended i.e. BIT_BKG_FK_I

The project I am on at the momment has around 250 tables and this approach gets more sensible the larger number of tables.

I agree with ORACLE name lengths it must be a real issue for them not to change it. A company that has produced what they have done surely would have made that change long ago if they could. From the outside you imagine it is like falling off a log.

One solution, the one I’m using currently, is to have an alias feature “in between” where truncated table names, or renamed to whatever, in the database is only a configuration issue (code still uses “full” names). I’d drop that in an instance though, if Oracle just entered the modern age.