Re: Conceptual, Logical, and Physical views of data
Date: Thu, 08 Sep 2005 12:15:33 GMT
Message-ID: <FXVTe.26582$FA3.9515_at_news-server.bigpond.net.au>
dawn wrote:
> 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). >> >>Given "it takes two to Tango" I would be prepared to argue the tension >>actually arises from the other side.
>
> 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.
Perhaps! However I place my bets on the RM side of the table because as a practitioner I find working around those restraints to achieve an end as better bet than starting with an easy platform and than having to tension up the finished product. This approach creates more certainty in mitigating my inherent laziness!
>>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.
Not sure of your intended purpose in the reference above to procedural code. Can you clarify the intention rather than me simply infer something from the grammar?
[..]
>>Quite normal expectations - we all want safety nets when doing trapeze >>work. However I simply accept the need to start with a low workout >>before the show and then progress to the high wire for the paying >>customers, rather than cuffing it with no rehearsal.
>
> 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.
In my case I still do the show with the "safety net" installed - it is not optional equipment! The art of stunning the paying onlookers is to prepare yourself for the show to an extent such that you never call on it to save your butt!
Regards, Frank. Received on Thu Sep 08 2005 - 14:15:33 CEST