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
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 M
On Sun, Dec 17, 2000 at 09:43:48PM -0600, Christopher Browne wrote:
>
> And the issue is _quite_ to the point, irrespective of anything
> having to do with MySQL.
>
> The examination of DB schema has thus far concentrated on what the
> field types need to be; that is important enough, but only g
On Sun, Dec 17, 2000 at 09:54:32PM -0500, Jean-David Beyer wrote:
> David Merrill wrote:
> >
> > On Sun, Dec 17, 2000 at 08:49:02PM -0500, Jean-David Beyer wrote:
> > > Christopher Browne wrote (in part):
> > > >
> > > > This is something that is indeed appropriately generated in the "engine,"
>
On Sun, 17 Dec 2000 21:54:32 EST, the world broke into rejoicing as
Jean-David Beyer <[EMAIL PROTECTED]> said:
> David Merrill wrote:
> >
> > On Sun, Dec 17, 2000 at 08:49:02PM -0500, Jean-David Beyer wrote:
> > > Christopher Browne wrote (in part):
> > > >
> > > > This is something that is inde
David Merrill wrote:
>
> On Sun, Dec 17, 2000 at 08:49:02PM -0500, Jean-David Beyer wrote:
> > Christopher Browne wrote (in part):
> > >
> > > This is something that is indeed appropriately generated in the "engine,"
> > > not in the DB; the relevance to the DB is to ask whether it can use the
>
On Sun, Dec 17, 2000 at 08:49:02PM -0500, Jean-David Beyer wrote:
> Christopher Browne wrote (in part):
> >
> > This is something that is indeed appropriately generated in the "engine,"
> > not in the DB; the relevance to the DB is to ask whether it can use the
> > GUID as one of its keys, and wh
Christopher Browne wrote (in part):
>
> This is something that is indeed appropriately generated in the "engine,"
> not in the DB; the relevance to the DB is to ask whether it can use the
> GUID as one of its keys, and whether or not the DB supports foreign keys.
What is this "foreign key" stuff
algorithm is working. So there is no reason to
> > > change it, but I'm doing essentially a new implementation of that
> > > code, so I want to make sure it is solid in all respects. Possibly
> > > postgres has a built-in guid factory as Oracle does, and this i
ng essentially a new implementation of that
> > code, so I want to make sure it is solid in all respects. Possibly
> > postgres has a built-in guid factory as Oracle does, and this is a
> > nonissue anyway, so let's not argue over it. :-)
>
> I don't understand.
10 matches
Mail list logo