column data typing

[Stef]

Has a beginner I want to understand why there are two data types defined on a column : SQL data type and data element.
The product documentation nor help is not any good in describing the sql data type any better than repeating its name. Help says that data element usage is optional but enables stricter data typing in the design!...then whats are advantages and possible disadvantages ?

here is the context for my questions: in my first server job (from ch 2 of DS designer guide) migrating a universe table to a seq file a date field is converted to a month tag; I forgot to assign a date data element to an input column of sql type Date. Then Month.tag(dslink1.date) was giving me a date in format yyy-mm-dd instead of a month tag. I thought that SQL type date was enough for DS to use month.tag; on top of that the compiler does not complain and execution seems to go well. is the transform funtion missing any input check ? it certainly does not provide a month tag in that context.

what are best practice regarding data element usage and is it broadly followed by DS community ? I read a post from 2001 archived data saying data elements are not very used (as people feels no benefits I guess!) May be time has passed and things changes a little bit ?

please help me to understand all this

[Stef]

Hello again,

I was told one way to "fix" this is w/out using the data element is:

month.tag(iconv(dslink.date,"D YMD"))

I suppose not assigning a data element DS assume it as a string (may be?) Whyis not internal date the default data element used in this case ?

Thanks....Stef

[ray.wurlod]

Data Elements are like "luggage tags" for data. They are meaningful only within DataStage.

For example, you have a ten digit number, defined with an SQL data type of Char(10). You have lots of these; they are different things. Some are telephone numbers, some are product codes, some are barcodes, and so on.

You can create Data Elements called "TelephoneNumber", "ProductCode" and "BarCode" (and "Revenue" and "Money" and so on), and tie these to the data within Columns grids. This gives four advantages.

• Usage Analysis will show where all ProductCodes appear in the project.
  
  Some automatic conversions (for example dates in ODBC stage) will occur so that you don't have to code them.
  
  If choosing DSTransforms in expression editor, intially only the Transforms that generate that data element are displayed; so the developer can more rapidly choose the correct one.
  
  The Data Element definition allows you to have a place to document business rules associated with the specific data element. For example, while an Indian telephone number is always ten digits, the area code may be from two to five digits, the remainder being the line number, unless the first digit is 9, in which case the next four digits are the carrier and the remainder the instrument number. Where else (within DataStage) would it make sense to store this business metadata?

[Stef]

Ray,

I understand your point.
Is it really used ? if not why ?
If seems like a good thing to me but I was told nobody uses it.
Do you recommend it to me for other reasons of documentation purposes?

Thanks.

[ray.wurlod]

In a word, laziness.

People know it's not essential for operation of DataStage, so don't bother. In many places the same problem exists for documentation; people realise that it's not necessary for operation of DataStage so they don't bother with that either.

It's a sad indictment on the way the world is.

[ray.wurlod]

If you're grouping a column in the Pivot stage and that column contains unique values then, just like in SQL, there's nothing to group.

Can you post a specific example?

[Stef]

Hi Ray,

I am a little bit confused about your statement; May be you wanted to post it on the 'delete dependant tables' thread ? but I don't use a pivot in that job so...
please explain

[ray.wurlod]

Quelle embarrassment!