- The kajillion functions and their syntax/calling mechanisms is one
'masterization' impediment. I will add that you don't see books on these
tools simply because there isn't enough licensed copies of them in existence
for publishers/authors to make any money.
- Yes, EDI mappings can be extremely difficult/complex. Some tools handle
differing flavors of these better than others. I doubt any one of them does
well at all the different spec's out there.
- I agree that an ETL tool will actually be an IMPEDIMENT to productivity
IF you are not INTIMATELY FAMILIAR with that tools interface, flow logic,
conditional logic, and functional capabilities.
- As far as the tools go, I do not believe there is such a thing as
'transferrable skills', unless several of them use VBScript (DataJunction
does this) or some such. Your comparison to C++/Java or SQL is flawed, in
that those are VERY limited, pretty much fixed sets of
keywords/logic/processing.
To answer your reiterated questions:
- I don't think the ETL tools are necessarily difficult to learn, they will
just take time/practice with them. Still, if "I" were a recruiter, I
wouldn't give you the time of day for anything other than an entry level
ETL-tool job unless you already had significant experience and /or training
on the product my company used.
- The primary advantages to ETL tools are that that provide a (reusable)
framework for logic/flow/parsing and built in capabilities for data/file
movement and error handling. I would NOT want to hand-craft a system to be
able to parse and process an ANSI X12 document!!
- I don't know much about PLSQL, but if it is a robust G3/4 language with
very good data handling, conditional, procedural and I/O capabilities then
you probably could roll your own ETL with it. Good luck with that if you
try it. :-)
--
TheSQLGuru
President
Indicium Resources, Inc.
<dba_222_at_yahoo.com> wrote in message
news:1176995593.936269.18150_at_y80g2000hsf.googlegroups.com...
> OK. But I still have questions.
>
>
> Is it because there are 3000 built in functions
> and commands specific to the ETL tool, and a number
> of new paradigms, that you first have to master?
> Since I don't see big thick books on the tools,
> if any, I don't believe this is the case.
>
>
> Or, is it that the new esoteric mappings themselves are
> difficult? They always are. In which case, I conclude
> that it doesn't really matter whether you use an ETL tool, or
> hard code it, the mappings will be difficult either way.
>
> Actually, I can imagine that an ETL tool may actually
> slow you down, because it's more limited in functionality
> than hard coding. In which case, I can understand that
> you will need to spend time with the tool, trying to
> get it to do the things that it wasn't designed to do.
> Is this the case?
>
> The idea that I'm getting at is transferable skill sets.
> If someone knows C++, they can learn java much easier
> than one without the OO knowledge. If one knows databases
> and SQL in depth, and can hard code ETL, this is also
> a transferable skill set.
>
>
>
> Again, Questions:
> - Just how difficult are these ETL tools to learn
> for an experienced Oracle pro like myself?
>
> - Other than a GUI, making everything simple to use,
> just what are the advantages of using ETL tools?
>
> - what built in functionality do ETL tools
> have, that can't be done in PLSQL?
>
>
>
>
>
Received on Thu Apr 19 2007 - 13:38:54 CDT
