Re: OO and relation "impedance mismatch"

From: Laconic2 <laconic2_at_comcast.net>
Date: Thu, 7 Oct 2004 07:56:39 -0400
Message-ID: <TP2dnbrQDuiQsvjcRVn-uQ_at_comcast.com>


"Kenneth Downs" <firstinit.lastname_at_lastnameplusfam.net> wrote in message news:fos1kc.6fc.ln_at_mercury.downsfam.net...

> Very tough call, buy or build? I don't like to be dependent upon a third
> party, which is why I'd like to be in control of the authoritative format
> for the dd. It has also seemed to me that the makers of these tools are
> usually trying to accommodate models such as ERD that I tend to ignore,
> owing to the fact that "People Understand Tables Just Fine." I think in
> terms of tables and want to specify things in terms of tables. And
because
> I can type, I have no reason to use a GUI to make pictures of tables whose
> essential information I'm just going to have to type anyway.

Over the last thirty five years, I have gradually progressed from tool maker to tool user. I like to think I'm older and wiser, but it's always possible that I'm just older and stupider. Example: in the 1970s I knew an operating system down to the bit level. Now I'm just a windoze user, and not even a "power user" at that. BTDT.

I differ with you about whether people "understand tables just fine", but that's neither here not there. The key to me is that, using DA, a conversion from ERD to SQL, with a diagram for each, is as easy a doing a spell check in my email program.

There are differences: if I have a many to many relationship such as bewteen students and courses, the ERD will prepresent it as a line with crow's feet at both ends. The physical data model (PDM) diagram will contstruct a box between the the boxes for students and for courses, with two foreign keys in it. DA knows all about that, and does it for me.

>
> But they do make really nice pictures, which it would be extremely silly
to
> re-implement.

In the course of adapting to being a "tool user" instead of a "Tool maker" I've learned to make all sorts of compromises between the way I think it really oughta be, and the way the tool is intended to work. I really do like theory (else why would I frequent this place?). But I'm guilty, and unrepentant, of what Leandro once called "that anglo-saxon infatuation with pragmatism."

Let me give you an example: I had just finished building a star schema for a client, and I wanted a pretty picture of it to leave on the manager's desk, for tomorrow. It was the end of the day, I was tired, but I wanted to do one more thing before going home. I didn't have a tool like DA, I can't make a pretty picture by hand, and I wasn't about to learn some artsy thing like "paintbrush" to do this work for me.

Well, I started mucking around with the available tools, and pretty soon I discovered that, if I created table links from MS Access to all the tables in my star, and explained some of the relationships to Access, and then cranked up the Access "relationship diagram", I would get a picture that was close enough to what I wanted. I had to move the boxes around o make it look like a star, but that was just drag and drop. At that point the "infatuation with pragmatism" kicked in. I printed the diagram, and I went home.

>
> So I haven't figured out yet how to relate to them. I have always assumed
> an import/export system.

How about ODBC (for reverse engineering an existing Database)? That's what I used DA for first. A tool to make in one hour a diagram of a a 100 table database that would have taken me a week to make without tools. Actually, I used a
DDL export from the DBMS, and an SQL reader parser that was part of DA, but it also had a DBMS interface.

> This is the fun part, but it is also where you spend most of your time as
> the toolmaker. This is another reason though why I tend to ignore the GUI
> analysis tools, because writing the code generator and DDL generator is
the
> real cool stuff, and frankly I just type the dd specs into text files,
> because that's the fastest way to get them created.

Whatever you do, make it fun.

>
> When I have it ready for others to use though, it will be pretty important
> to allow GUI editing, so a bridge to freely available open source tools
> will become much more important.
>

I like a bridge, but I don't demand "open source". As long as the damned tool has an "export" button, I'm willing to live with "closed source".

> Hmmm, had no plans, I'm kind of SQL bigoted. But since it will be GPL,
> perhaps you can add that?

I'm pretty partial to RDM myself. But, unlike the real bigots in this forum, I treat SQL as "close enough to relational for consulting work." I'm no purist. I'm to old for that. Received on Thu Oct 07 2004 - 13:56:39 CEST

Original text of this message