Re: Two-valued logic

From: Dawn M. Wolthuis <dwolt_at_tincat-group.com>
Date: Tue, 30 Dec 2003 15:05:09 -0600
Message-ID: <bsspa9$gj2$1_at_news.netins.net>


"Mikito Harakiri" <mikharakiri_at_iahu.com> wrote in message news:oilIb.10$7S6.193_at_news.oracle.com...
> "Dawn M. Wolthuis" <dwolt_at_tincat-group.com> wrote in message
> news:bsslkh$2la$1_at_news.netins.net...
> > This model seems to have good solutions to
> > questions such as whether or not to use multivalued logic without having
> > considered all options by thinking in terms of what would be most useful
> to
> > their customers..
>
> Oh, please. Praying for the customer benefits doesn't automatically give
you
> insight into superior solution.
>

You are absolutely correct. In fact I would suggest that starting with a solid model and implementing it would be the better approach. If I had not seen it with my own two eyes, I would have expected projects that employ relational databases to excel in at least software maintenance productivity, but, alas, that is not the experience I have had. To be certain that my 25 years in this profession were not simply abberant in this regard, I have "asked around" and there seems to be a significant number of professionals with similar stories.

So, if you have other theories of why so many folks (especially those who are paying) who have used both RDBMS solutions and other non-RDBMS database implementations have favored the non-RDBMS efforts, I'm all ears. I'm sure there are folks who have had the opposite experience as well, but my interest right now is in determining why the Nelson-Pick databases have had such a significant following for so many years (birthdate is considered around 1965), including companies considering it their secret weapon against competitors. But still it has no backing from the academic community (not even taught in colleges) and generally sits below the radar.

When I first saw PICK (in the form of Pr1me Information) as a manager starting a new job, I remarked "that's not a database!" and was then overwhelmed by the productivity my new team had when using this "not a database" as a means for storing and retrieving data. I'm trying to figure out why this is the case and to square up database theories with experiences.

Thanks. --dawn Received on Tue Dec 30 2003 - 22:05:09 CET

Original text of this message