Re: Conceptual, Logical, and Physical views of data

Frank Hamersley wrote:
> dawn wrote:
> > David Cressey wrote:
> >> "dawn" <dawnwolthuis_at_gmail.com> wrote
> >>> David Cressey wrote:
> >>>> "dawn" <dawnwolthuis_at_gmail.com> wrote
> [..]
> >>> An aside -- it seems to be less expensive to migrate from one
> >>> non-SQL dbms to another than from one SQL-dbms to another.
> >>
> >> I disagree completely. In my experience, it's just the opposite.
> >> Tables and indexes port very readily from one SQL DBMS to another.
> >
> > Constraints? Derived data (e.g. stored procedures)? SQL code (and
> > ODBC)?
>
> I haven't ever had trouble with these elements per se!

Great -- I'm really glad to know that, even if surprised.

> Of course
> migrating poorly constructed solutions (often with the hallmark of low
> degrees of rigour) is never easy regardless of the tools used or to be used.

agreed

> >> I've never attempted a port from say IMS to VAX DBMS or vice versa,
> >> but those who have report to me that's it's very difficult to sort
> >> out what features of the design are product specific from what
> >> features are generic.
> >
> > Sounds likely. My experience has been that it was more difficult to
> > map between modeling approaches when one side (source or target) is a
> > SQL-DBMS. Other models map more handily to each other. Perhaps
> > this is because you don't have to split out all of the weak entities
> > for most non-SQL-DBMS products, or maybe because more of the
> > constraints are in the code rather than converting them between app
> > code and dbms code. I don't have enough experience in this regard to
> > generalize, however (no OO-DBMS experience, for example).

>

I think of it as arising from the combination. The SQL-DBMS has more requirements, so you could interpret the problem as coming from either the side that is too strict or the side that is not strict enough.

> IMO the laxity (or flexibility when speaking in +ve terms) of feature
> laden or low discipline products, whilst producing quick and easy
> solutions to apparently knotty problems, is lethal for instance when the
> life-cycle issues of maintenance by non original staff etc eventually
> arise.

There is part of me that still believes that in theory. I've seen some awful spaghetti code (I contributed to some in 1977, but I learned and I apologize), but if you stear clear of poorly-written or non-OO, procedural code, then the flexibility you gain with more agile dbms products follows you into the maintenance cycles which then do not look so different from the initial development iterations.

> This issue of instant gratification is exemplified by the MS
> sponsored diet of Fairy Floss (sugar) proffered by tools such as Access
> and DTS.

I'm with you there.

> I don't think I would be alone in bemoaning the number of
> times a concept solution has been presented using those type of tools
> with an expectation of it being corporatised quickly and cheaply given
> that all the "heavy lifting" of determining the business rules has been
> done!

If you select tools that do no scale for features, performance, size, or whatever, then you run into that type of problem. That is not the same as solid DBMS products that are not "relational" (e.g. Revelation, Cache', IBM U2)

> >>> If your application logic is in your code instead of your dbms,
> >>> then you can point your code at something else, while if you have
> >>> application logic (e.g. constraints) in your dbms and you switch,
> >>> you need to recode that application logic in your new proprietary
> >>> language that might be something like the previous one, but often
> >>> not close enough. cheers!
> >>
> >> All programmers feel this way about databases. Your problem isn't
> >> that you don't like relational databases, or the relational data
> >> model. Your problem is that you don't like databases, period.
> >
> > I'm almost willing to say "Good catch, David". I might lean that
> > way. However, I do want support for transactions, backup & recovery,
> > logging, security, derived data, query languages, indexes, caching,
> > logical schema, ... . I suspect SQL is more of an issue for me than
> > the relational model now that the relational model seems to have
> > evolved to include what was once non-1NF (NF2). I do want
> > navigational operators, however and that seems to go against
> > relational theory. I want to "click on" a foreign key value and
> > navigate to the referenced entity.

>

For some odd reason, I follow your line of, uh, reasoning there. However, I think that I want these operators for good reason and not just as a safety net.

> Its not much
> comfort to blame the catcher after a splat!
>
> Cheers, Frank.

cheers back atcha. --dawn Received on Thu Sep 08 2005 - 04:36:28 CEST