Re: foundations of relational theory?

Anthony, I was going to comment that it's not useful to talk about efficiency because from a theretical point of view, it is irrelevant. Someone else (the programmer) takes care of the details. Then I saw:

 >>[snip from John Gilson, thanks for the illustration, this is most helful in spite of the comment below]
-- maintain constraint that consecutive business dates be mapped to consecutive -- natural numbers
date_count INT NOT NULL UNIQUE
CHECK (date_count =

          COALESCE((SELECT C1.date_count
             FROM NYSECalendar AS C1
                 WHERE C1.business_date =
                  (SELECT MAX(C2.business_date)
                    FROM NYSECalendar AS C2
                    WHERE C2.business_date < business_date)) + 1,1))

Now, if I read this right (and if not, please correct me,) in order to get a unique next id, there's two conditional table selects. Compare this to how we'd do in procedurally-maintain the last number, read under lock and add 1 and write the record; an order of magnitude faster? or several? Now maybe Informix manages to parse these to something more efficient?

My point is that you cannot afford to ignore implementation efficiency even with the speed od hardware nowadays -daily example- does your PC boot up in 1000-th the time your 386 used to?

John Gilson continues:

 >> In a DBMS that doesn't allow subqueries as declarative constraints, such as SQL Server, then triggers can be defined for the same effect. Triggers are procedural objects, basically like stored procedures just invoked automatically, but they do reside in the DBMS.

This is how you can do it in Pick as well, so functionally there's no difference in maintaining constraints.

Chandru Murthi

Anthony W. Youngman wrote:
> In article <JIwnb.38666$9E1.147949_at_attbi_s52>, Marshall Spight
> <mspight_at_dnai.com> writes
>

>>"cmurthi" <xyzcmurthi_at_quest.with.a.w.net> wrote in message news:3F9E7BFE.7050400
>>_at_quest.with.a.w.net...
>>
>>>Perhaps
>>>this can evolve to a discussion of priorities and strategies in
>>>application development instead of purely theoretical niceties.
>>
>>I'm interested in practicalities, but I'm also interested in
>>theory. The big reason I read c.d.t. is to further my interest
>>in theory. When I'm at work, I'm Mr. Practical. When I'm
>>home, reading newsgroups, I put my theory hat on. So
>>I actually have a *cultural* bias against discussing practicalities
>>while here. (Plus, I already get a steady diet of that.)