Re: SQL Server 2000 Migrate to Oracle

From: Galen Boyer <galenboyer_at_hotpop.com>
Date: 30 Aug 2004 09:49:05 -0500
Message-ID: <u4qmkk7j4.fsf@standardandpoors.com>

On Mon, 30 Aug 2004, hjr_at_dizwell.com wrote:
> Galen Boyer wrote:
>

>> On Mon, 30 Aug 2004, hjr_at_dizwell.com wrote:
>>> C Stabri wrote:
>>> 
>>>> I am trying to get some tables out of SQL Server 2000 and
>>>> into Oracle 9i. However I am encountering problems.
>>>> 
>>>> 1. Many of the tables and column names in SQL server are >
>>>> than 30 Characters which meansa any auto inport I do fails.
>>>> Is there a way to get around this.
>>> 
>>> Yup. Open the relevant table in SQL Server, and start editing
>>> the column names.
>>> 
>>> I'm sure you will tell me there's a perfectly good reason why
>>> your column names are so ridiculously long. But I won't
>>> believe it, so don't.
>> 
>> Here's an attribute name:
>> 
>>   financial information submission failure penalty
>> 
>> This is spec'd out by the business I'm the datamodeler for,
>> but I guess I'm in a ridiculous business, just like the OP
>> cause my database doesn't support that name?  I abbreviated it
>> to, finclinfsubmfailpnlty.  I kind of think the fully spelled
>> out version is easier to understand.

>
> I would have gone for fisfp myself. Or fispnlty
>
> Nowhere near 20 characters, still less 30.
>
> Actually, I might just have gone for COL14. Who knows?
>

>> 
>> Howard,
>> 
>> For the first time in my years reading this board, I feel like
>> I'm reading a posting from the soapbox of Daniel Morgan.  The
>> truth is that the <= 30 limit is just that, a limitation. 

>
> But it's a limitation that's there because Oracle, in their
> wisdom, thought that no sensible people would absolutely have
> to have more than 30 characters. Now, they've made stupid
> decisions before, but this ain't one of 'em as far as I'm
> concerned. I can abbreviate your long-winded name in 9
> characters, not 30. In 5 if you'll let me.

I can beat your crypticness. I can create a single character UNIX script, q.sh, which will solve everybody's needs. Sign of a good lazy programmer. But, not all that descriptive, that's for sure.

> If you think that's soap-boxing, so be it. It happens to be
> common sense, I think, not to put too much meaning into table
> names or column names.
>
> I worked with a designer once whose suggestions for table names
> read like an essay. When I asked why he wanted a table called
> 'GroundsMaintenancePeriodWork', he said it was to help the
> users. When I pointed out the users would never see such a
> table name anyway, we settled on TblPdWk.

I do it to help the development effort, not the end users. It certainly helps me when I do a desc on a table, even when I designed the table.

> And I know a lot of people who would get ticked off with the
> 'Tbl' part of that name.

Let em get ticked.

>> It 
>> makes one come up with, to use your adjective, "ridiculous"ly
>> difficult to understand abbreviations.

>
> It assumes one is supposed to understand them. Frankly, you
> could call tables BLAHx and still have a functioning
> application.

Thats not my point.

>> Its a limitation and there is nothing but drinking the Oracle
>> coolaid which makes one try to argue differently.

>
> Wrong. One can look at design principles and see that long
> names are, well.. I don't know what else to call
> it. Ridiculous is the only word that springs to mind.

Okay, if thats supposedly the argument. Is it actually written somewhere, "Though shalt not have > 30 characters ..."

>> That is why I don't understand your posting.  You definitely
>> don't drink the Oracle coolaid, but for some reason here, you
>> try to defend the limitation as though it somehow helps the
>> datamodeler by requiring him to come up with names <= 30.

>
> I don't even know what drinking the coolaid means (and yes, I
> know all about Jonestown). I don't know why you would think
> that table names or column names should be arbitrarily long!

Same reason it easier to maintain application code. Descriptive names for variables make easier maintenance of code.

> Let me put it this way: I have never met a design that actually
> *needed* long table or column names.

I've never met an application with variable names like "var1, var2" that was easy to maintain. Same thing with column names in tables.

> I have even worked with an application, perfectly happily,
> where every table had a primary key column called 'CODE' and a
> descriptor for the code called 'DESC'.

I think thats a fine idea, as long as you are consistent across all tables. It certainly lends itself to easier bridging between object designs and relational database stores.

>> Oracle has limitations that are annoying.  This is one of
>> them.

>
> Disagree.
>
> That I disagree with you doesn't make my post a Daniel Morgan
> Soapbox job.

You weren't disagreeing with me. You were scolding the OP, when he just asked a simple question.

> It doesn't make it an attack on you. It doesn't make it
> anything other than a statement of my opinion based on my
> experience. Which all my posts are, incidentally.

I understand your point. All the OP said was:

  >> 1. Many of the tables and column names in SQL server are >
  >> than 30 Characters which meansa any auto inport I do fails.
  >> Is there a way to get around this.

You then sarcastically slammed him on his design. I then chimed in to disagree with the crux of your design statements, and I labeled it as a soapbox. I'll tell you what, let me apologize for the soapbox comment. It isn't the point of this argument and my labeling your comments as a soapbox puts me on my own soapbox. Not conducive to a good argument.

-- 
Galen Boyer

Received on Mon Aug 30 2004 - 09:49:05 CDT