Re: Conceptual, Logical, and Physical views of data

"Frank Hamersley" <terabitemightbe_at_bigpond.com> wrote in message news: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 had trouble with constraints as such.

Stored procedures, SQL code and ODBC are about data processing, not about storage and retrieval. Even there, the difficulties I've observed are due to the failure of the DBMS builders to conform to a standard, rather than inherent problems with SQL or the data model itself.

I think you've really hit on something when you talk about "low degrees of rigour". I would include under that, discovering that some analysis was really premature design, but never putting that discovery in writing, as Dawn suggests. That's laying a trap for the team that comes along to revise and extend later.

> 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!
>

This is a knotty problem. On the one hand, prototyping can be a very useful adjunct to other forms of requirements analysis. On the other hand, non technical people can seldom understand why it's a good idea to throw the prototype away, and build from scratch, once you have understood the problem. What we need is a way to make issues of scale visible to people graphically. If we showed someone a four foot model of the replacement for the World Trade Center, they wouldn't imagine that building the real thing would be "easy".

Then again, it should be quicker and less costly than it is now to turn a correct and detailed analysis into a deliverable product. That's another discussion. Received on Thu Sep 08 2005 - 13:32:03 CEST