Re: does a table always need a PK?
Date: 1 Sep 2003 05:53:27 -0700
Message-ID: <bcb8c360.0309010453.7b5a9767_at_posting.google.com>
paul_geoffrey_brown_at_yahoo.com (Paul G. Brown) wrote in message news:<57da7b56.0308311128.3b6d4518_at_posting.google.com>...
> Put it another way: as much as folk would love to be able to say things
> like "I don't care about implementation details: we're talking about the
> logical model here.", it simply doesn't cut much cheese. In the end you've
> got to have a working system or no one (outside a small circle of friends)
> cares because what you have is impractical.
>
mmm-hmmmmm........
> Recall the lambda calculus? A powerful and complete system for reasoning
> about computation that gave rise to a number of computer programming
> languages most notably LISP. But look where that model is now. And why?
> Because implementing it was a bear. And for all the huffing and puffing
> you hear implementing a working semi-Relational DBMS is *really* hard.
>
Really ? Where *is* the lambda calculus now ? I'd say it was ticking
along quite nicely, actually. For example, providing the software for
Ericsson telephone exchanges (in the syntax sugar edition known as
Erlang). Have a read at Simon Peyton-Jones' "Implementation of
Functional Programming Languages" some time (it dates back to 1987/88;
I'm sure the state of the art has moved on even further since then).
It's not *that* much of a bear.
Implementing *any* non-trivial piece of software is *hard*. There is always a price to pay for your choice of level of abstraction; too low and you drive yourself nuts with implementation details but the program might go fast, too high and you code pretty quickly but the program might go slower.
- Tony