Re: Conceptual, Logical, and Physical views of data
Date: Thu, 08 Sep 2005 00:43:35 GMT
Message-ID: <XOLTe.25991$FA3.1681_at_news-server.bigpond.net.au>
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! 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.
>> 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).
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. 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 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 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.
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. Its not much comfort to blame the catcher after a splat!
Cheers, Frank. Received on Thu Sep 08 2005 - 02:43:35 CEST