Table Name as Parameters in all the jobs

[swarnkar]

Hi All,

We have started a new Datastage Project 6 month back,
There we have decided to you Parameterized the Table Name/File_Name
along with DB COnnection Name, User_Name,Password and Schema in entire Project.

We are using a Parameter_Set to keep all the Parameters.

Now, as the number of Tables (Source/Target) are increasing,
our Parameter Set is also getting bigger and
so far we have around 300 entries in our parameter set.

Since this entire code has to go through some changes
to make it Production Ready, We are thinking Is is really
good practice to use Parameters for Table_Name and FileName,
and if we decided to keep on maitaining it
what will be challeges we might face.

Please advice me, with possible Pros and Cons.

Thanks & Regards
Nitin Swarnkar.

[ray.wurlod]

Size in the hundreds should not be a problem.

[greggknight]

Just to give you an Idea this is how we are doing it.
currently we have 80 dimensions and 5 facts
alot more facts to come in phase two.

What we did was create a local parameter called #TableName# which is local to each job. Since each job is specific to a table the name will never change at run time from our batch but we cold change it if we ran the job manually.

Then we use the parameter in our other jobs which create datasets and so on.
like #PROJECT_DIR##DataSetFileDirectory##COMPANY#_#TableName#_upd.ds
All but #TableName# are Reand from an ini file and can be changed at runtime.

The same applies for the Database connection and the Database and the User id and the password. They are all in the ini file as well.

We are not using schema files for these processes so it works well. All the files are named by the tablename and company so they stay unique.

We do use schema files for other jobs though.

Just an Idea.

[swarnkar]

Thanks Ray and Thanks Gregg.

Regards,
NItin Swarnkar

[prakashdasika]

Denormalize the paramete sets, for example we use one set for all unix paths, one for oracle connections, one for the tables etc.. It is easier to maintain, and as you might have known that when the parameter set gets updated the jobs that use it have to be recompiled, it beomes easier to maintain with this technique.