GUID Factory

[Jean-David Beyer]

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.
> 
> The examination of DB schema has thus far concentrated on what the
> field types need to be; that is important enough, but only goes half
> way towards describing the data.

Of course it goes only part way to describing the data, though I would
not phrase it that way myself. Assuming the present description of the
field-types to be complete, it goes all the way to _describing_ the
data; what is not there is the description of the _relationships_ among
the data. The reason I quibble about the phrasing is that one of the
benefits of the relational model is that these two items can be
considered separately. In fact, provided that the database design, as
far as what relations exist, and as far as what the attributes of the
relations are, you can add new relationships, and change existing
relationships, rather easily, something much more difficult with other
data storage methods.

> 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.

As far as foreign keys are concerned, what do you think a foreign key
relationship is? This just defines a particular kind of relationship
between two tables (relations). It says that for an entry (tuple) in one
table (let me call it a child-table) to be valid (and thus, to exist),
the contents in one field (attribute) must be a value that exists as the
value of the primary key of another table, that I will call the
parent-table. So you cannot enter a row (tuple) of the child table
unless that field-value is already present as the primary key of the
parent table. It also insists that if you remove the row in the parent
table that something pretty specific must happen in the child table.
Usually that means that you cannot delete the row of the parent table at
all unless all the corresponding rows of the child table have been
previously deleted OR that when deleting the row of the parent table,
the dbms automatically deletes the corresponding rows of the child
table, the choice being up to the database (not DMBS) designer.
(Actually, there could be many child tables using the same primary key
in the parent table, and this would apply to all of them. And they need
not all have the same enforcement rule.)
> 
> 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.

[snip]

-- 
 .~.  Jean-David Beyer           Registered Linux User 85642.
 /V\                             Registered Machine    73926.
/( )\ Shrewsbury, New Jersey
^^-^^ 6:40am up 13 days, 15:27, 2 users, load average: 3.09, 2.99, 2.57