one project or multiple

Post questions here relative to DataStage Enterprise/PX Edition for such areas as Parallel job design, Parallel datasets, BuildOps, Wrappers, etc.

Moderators: chulett, rschirm, roy

Post Reply
jasper
Participant
Posts: 111
Joined: Mon May 06, 2002 1:25 am
Location: Belgium

one project or multiple

Post by jasper »

Hi,

At this moment we have a 7.5 environment with one big production project (3000+ jobs and flows). Untill now we haven't had any issues with this size.

I'm now planning a move to a datastage 8 environment (it will not be an upgrade, it's a new install on new hardware, new DB,...) and I thought this would be the time to make a decision about splitting this project or not.

What do you consider the biggest advantages or disadvantages of having multiple projects? Is there anything new in DS8 that has an impact on this?

Reasons we kept it in one project:
- routines, jobs, flows that are used in a lot of flows are kept in one location.
- easier to work with lookups and datasets.
- no overhead of importing source metadata into all projects.
ArndW
Participant
Posts: 16318
Joined: Tue Nov 16, 2004 9:08 am
Location: Germany
Contact:

Post by ArndW »

I think you've got a fair idea of the advantages and disadvantages already. With V8 you get better search and metadata handling; so if y project is split you will have to take care of replication of common elements across that project boundary.

3000+ Jobs and associated objects is quite a bit and my gut feeling is that this is best split into several projects. Common elements can be made read-only in projects where they should not be changed, making maintenance less of a nightmare.

It will probably boil down to whether or not the jobs themselves fit into groupings that can correlate to projects. Remember, if you have a typical Development, Test, Production split then you will most likely have to make this change in all 3 environments.
wesd
Participant
Posts: 22
Joined: Mon Aug 16, 2004 8:56 pm

Post by wesd »

I would consider any logical areas for a split if you wanted one. For instance, you could split by target systems or subject areas. I'm not a big fan of multiple production projects as it leads to more areas for code to get mis-migrated.

Agree with Ray though, sounds like you have a solid plan.
Wes Dumey
Senior Consultant
Data Warehouse Projects
Post Reply