Re: does a table always need a PK?

Hello,

"Heikki Tuuri" <Heikki.Tuuri_at_innodb.com> wrote in message news:<a613b.352$n62.327_at_read3.inet.fi>...
> please give a formal definition of a "DBMS". In the style of mathematics. It
> is like writing a formal definition what an "operating system" is. Or a
> formal definition what a "horse" is.
>
Hmmm... I have issues with that as an answer.

• A definition of a DBMS in the style of mathematics. Or, put another way, a formal mathematical definition of Oracle. An interesting project, that. (This immediately makes me think of continuation semantics, to handle the time progression side of things.) Not a trivial undertaking, but one that may be well worth someone's while doing. It would also be one heck of a long post.
• Formal definitions of operating systems... There was a fair bit of work done on this in the mid- to late-1980s, ISTR. Handling time properly was a real issue. One thesis I know of that started off as a formal def'n of an operating system had a six month diversion into representing and handling time turn into a thesis about representing and handling time, put it that way. The next problem is that operating systems work in the world of side effects when you're at the device driver level, and mathematics doesn't have a lot useful to say about that (hence monads in Haskell and the imperative bits of Standard ML to deal with I/O amongst other things). Maybe someone out there has an interesting pointer into the world of operational semantics for such things ?
• Wouldn't the formal definition of horse simply make reference to the genetic make-up of an equine beast :) ?

OTOH, if we're given a mathematically sound definition of what a relation is, and what the operators on relations do, then we at least have a starting point for what an RDBMS is (that is, a system which manages databases consisting of relations - weak but accurate) Of course, things get hairier when we go with multiple concurrent updating users and we have to worry about synchronising access to shared resources, deadlock management, transaction handling (spit), etc. etc. Given all the effort that would go into those things, you'd think we'd save ourselves some effort by sticking with those ol' mathematically defined relations & relational operators rather than reinventing that wheel too, wouldn't you ?

• Tony