Someone with greater expertise than I recently told me that it is best
to have an integer primary-key for all tables in a database, even if
the table already has some non-integer primary key, or some sort of
composite primary key. If there is already a non-integer key, then

I'm reading a new paper by David Lomet and Roger Barga, two respected
(I think!) senior researchers at Microsoft, and come across the
following in discussing the ACID properties of a DBMS:
"However, these techniques [Atomicity, Isolation, and Durable], which

On page 18 of the "New Algebra"
http://www.dcs.warwick.ac.uk/~hugh/TTM/APPXA.pdf
D&D express summarize via basic Tutorial D operators. This construction
is not obvious to me (especially that I'm not versatile in Tutorial D

One of the last posts on dbdebunk ("On conceptual modeling and database
design") included the following :
<quote>
My material is sound because unlike all the stuff floating in the

[apologies for the cross posting].
Bob Badour wrote:

Ok, I've had time to digest this now, and I have to say that I /do/

These series of posts compare the impact on existing
schema/data/queries in RMDB and dbd solutions as a result of adapting
to new data requirements in one particular example.  The example is
based on following article:

In an earlier thread, Marshall asked for a real-world example, and while
this isn't exactly what was asked for, it illustrates the problem.  Here's
the situation.  I have two databases containing orders.  One is the
customer's database containing purchase orders, lines, schedules ...

Are there any DMBSs apart from Dataphor that support foreign superkeys
without undue hassle? SQL systems support them in that a superkey may be
declared UNIQUE, and thus referred to by a foreign key, but I'm looking
for more explicit support.

I am putting together a team in Columbus Ohio to build a state of the
art website geared to revolution an industry (I have plenty of details
to go into for anyone who is interested.  I am looking for someone who
is entrepreneurial minded with the skills to be our DB architect.

I have a number of tables as below:
employee(*employeeid, ....)
schedule(*scheduleid, recur_interval, ...)
emp_schedule(*employeeid, *scheduleid, *valid_from, valid_to)

I'm working on a project where the logical data model stage slows the
process down. I'm not talking about thinking time, that is always there
as part of the process. I suppose the tool doesn't help. Oracle
Designer is just awful and you spend an awful lot of time changing the

I have table 1, whose primary key may be used in table 2 table 3 .... table
n, as a foreign key.
Is there any constraint that can applied, hopefully once and in one place,
that ensures that for any particular row in table 1, it's value is used in

I'm looking for some books on database design and theory and was
looking for some suggestions.  I have been dabbling with a database for
just a couple of months now and have quickly come to realize how
necessary it is to have some sort of a foundation.  So I'm looking for

As a result of ambiguity problems with colum names when performing a
join I discovered that MS SQLServer does not return the conventional
tablename.columname but only columname, which of course creates
problems.

I've been thinking about concurrency and transactions. It occurs to me
that much of the difficulty lies with the fact that multiple concurrent
transactions may operate on the same data. I begin to recall some
conversations from years past about "multiple assignment".