Compare DB2 - IMS/DB

[ranga_subham]

Hi,

Can we make comparisons between DB2 and IMS/DB? Is each table in DB2 called segment in IMS/DB?

Please explain.

Thanks.

[dick scherrer]

Hello,

No, not directly.

You could extract the data into sequential files of the same layout and compare these.

DB2 is relational - IMS is not. Suggest you not try to equate one to the other.

[Ed Goodman]

Hmmm.. tough question!

Imagine a very simple data situation: departments with people.
Each department has unique attributes, like address and budget
Each person has unique attributes, like name and hire date

In a relational database, you might break this up to have:
-a Department table, with one row per department, each row having address and budget fields
-a People table, with one row per person, each row having name and hire date
-an Xref table with each row department and person combination

In IMS, you might break this up to have:
-a Department database, with one root segment per department, each segment having address and budget fields
-a People database, with one root segment per person, each segment having name and hire date fields

Here's where the differences start to show:
In IMS, you can show the relationships between the two tables a few different ways
-add child segments under the Department roots, each segment POINTING to a Person root
-add child segments under the Person roots, each segment POINTING to a Department root

- OR -
-create an XREF table with Department/Person combinations

Now, the real difference is how you go about gathering information.
In the relational model, you join your tables and run your reports and queries from the result tables.
In IMS you start reading the one table, then go out and get the information from the other tables as needed.

The real power of IMS comes to light in more complex systems, where you can hang all of the related information about a department directly under that department's root in the database. It's kind of like you've "pre-joined" that relationship, kind of. You can find almost everything you need about that department in one place, without having to join it all together every time.

For example, in our system, we have personal assets stored under the person. We also have employment history stored under that person...and insurance coverage...etc. So all I have to do is jump to that person's root segment, then read through their information. It's already "joined" to them.

Now...this implies that when that information was added, we knew how it was going to be retrieved most of the time. If we knew were were going to have "show me all the insurance coverage in the system" type requests, we would have made that a separate table with pointers into the People table.

[Anuj Dhawan]

I've worked with both. My experiences says, IMS is faster than DB2 and data recovery is basically automatic. Before the invention of IMS, a lot of shops used VSAM which behaves almost like a sequential file - only with keys. This created a lot of data redundacy. IMS was developed for the first moon project. It was not originally an IBM project. To cover it in short, IBM got into the picture and millions of started using it, people came online.

So if you think of it this way, IMS is the child of VSAM - DB2 is a close relative.

Just my .02$...

[Akatsukami]

IIRC, IMS antedates VSAM by several years.

[dick scherrer]

Hello,

IMS is over 40 now.

I remember when we "upgraded" from ISAM to VSAM in the mid-70's.