Re: What is Pick anyway?

"DonR" <donr_work_at_yahoo.com> wrote in message news:1135744411.676896.96910_at_g49g2000cwa.googlegroups.com...
> David Cressey wrote:

> >
> > It's fairly common, in the development of new databases, that you are
> > integrating data that, in the status quo ante,
> > are managed by separate departments, using separate packages, purchased
from
> > separate vendors, and maintained by separate teams of programmers.

[snip]

> > In the scenario I'm outlining, you may be dependent on the expertise of
> > programmers in both the SALES and the PURCHASING departments to provide
data
> > feeds. Those feeds may or may not be consistent and/or reliable.
>
> Garbage in, garbage out.

That's a fine slogan for programmers. If you are interested in enterprise data integration, you have to move beyond that slogan. The enterprise data is what it is. You are not going to throw it all away and start over. You are going to start with the enterprise data, such as it is, and transform it onto a more consistent and better integrated body of data.

That's where my interest lies. And that's what I want do use databases for, mainly.

> Most companies running Multi Valued (aka Pick) systems run all the
> departments on one database, ie one set of interrelated files.

> My guess is the proprietary MV program can be written quicker and with
> finer details than a combination of database constraints and SQL
> whatif's. I think the problem you and other SQL programmers have in
> understanding MV is that you are trapped in the SQL box. ;-)

But that's only a guess. My guess is different.

> Right, managing the people can be a lot harder than managing the data.

Right. And managing data as an asset involves interacti with, if not managing, the people who turn that data into value.

> > The above comment seems to me to be about the PICK programming language,
> > and not about the PICK data model.
> >
> I normally don't think of these as separate entities. Many MV shops
> don't have strict standards. They may have only a couple of
> programmers, so it's not two hard to control things.
> Also, there are MV based and non-MV based source control systems that
> let you control and track program changes. I consider source control a
> must.
> >

It's useful to think about the data model as distinct from the programming language in certain contexts. Database theory, the subject of this newsgroup is one such context.

Only a couple of programmers? That suggests a scale to me.

> > That's fine, but unless you can explain how the Pick data model works
in
> > the scenario I'm outlining, I can't see
> > how I'd apply the same model to enterprise wide data integration. And
that's
> > where my head is at with regard to the application of "database theory".
> > (not "application programming language theory")
> >
> The MV database model basically is, you can store anything anyway you
> want. The dictionary and program logic defines the meaning of the data.
> As I stated in a previous post, the dictionary is optional if you want
> to program EVERYTHING. However, I consider a good dictionary a must.
> The dictionary is requried for access from outside the MV environment
> such as via ODBC.
>

Say some more about the dictionary. You consider a good dictionary a must. I consider an explicit data model a must. You and I may not be as far apart as it seems at first.

> > I may not have described the scenario I've outlined very well, but I
regard
> > the scenario as typical of database work.
>
> As a side note, one of the most popular ETL (Extract, Translate, Load)
> programs, Datastage, uses Universe as it's engine. Such a program could
> be used to validate and load data from and to multiple sources
> including relational databases.
>

Ahhh, ETL. Good. This is where "garbage in, garbage out" meets its match.

Say some more about Universe. How does it relate to Pick? Can the "L" part of ETL be loading the data into a relational database? Is this common practice? Received on Wed Dec 28 2005 - 13:12:28 CET