GUID Factory

[David Merrill]

On Mon, Dec 18, 2000 at 07:11:46AM -0500, Jean-David Beyer wrote:
> Christopher Browne wrote (in part):
> > 
> > [snip]
> > > >
> > > > Just that the primary place a GUID is used is as a primary key, and
> > > > foreign keys in those tables' child tables.
> > > >
> > > So of course an rdbms would support foreign keys, and this is a
> > > non-issue, right?
> > 
> > That assumes that MySQL is not considered to be an RDBMS that would be
> > a candidate.  Its lack of foreign key support is fairly conspicuous...
> > 
> > And the issue is _quite_ to the point, irrespective of anything
> > having to do with MySQL.
> 
> Well, what aspect of foreign key support is considered vital? If you
> make two relations, and one contains an attribute that is, in fact, a
> foreign key of another relation, and the dbms does not "support foreign
> keys", the only unpleasant consequence is that the child-relation (if
> you choose to call it that) could have a tuple with an attribute-value
> that is not present in the parent relation. This would be a pity, but
> the requirement that such tuples in the child-relation cannot exist
> could be enforced by other (though less desireable) means if people
> really wish to use MySQL. But this stuff could (should?) be hidden
> behind the dbms API I would imagine.

I don't consider it vital. It is highly desireable, however.

> > The _next_ thing that needs to be done is to outline the relationships
> > between table entries.
> > 
> > Assuming "standard" SQL, that might be outlined in the form of a number
> > of foreign key relationships.
> 
> Well, there is a standard SQL. The main problem is that some
> implementations do not comply with the standard. Some implementations
> are quite close. The problem here seems to be that the implementations
> some want to consider using may not comply sufficiently with the
> standard.

This will not be a problem. The areas where databases vary are easily
avoided if you know where they are. And this db is not going to
require anything fancy.

> > Supposing the SQL is "dumbed down" to the lowest common denominator
> > form supported by MySQL, that means that we need to establish what the
> > relationships are that the _engine_ will have to manage.
> 
> If MySQL does not support foreign keys, that does not mean that they
> could not be used. It means that the enforcement of foreign key
> relationships would have to be moved from the dbms, where it belongs,
> into the application, where it does not belong, complicating the design
> and construction of the application.

Foreign keys are a safety net. If you code does something egregiously
wrong, like try to write a transaction on a nonexistent account, the
db can recognize it and stop it from happening. That's all. They do
not provide any kind of assistance when writing code, other than
identifying b0rken code.

-- 
Dr. David C. Merrill                     http://www.lupercalia.net
Linux Documentation Project                dmerrill@lupercalia.net
Collection Editor & Coordinator            http://www.linuxdoc.org
                                       Finger me for my public key

Three from the hall beneath the tree
	Is, Was, and Shall Be
Come Wyrd Sisters swoop to the ground
Loosen the web that binds us down
Join with the hands of the Weavers Three
	Is, Was, and Shall Be
		-- Is, Was, and Shall Be, Beverly Frederick