PlayDB, PlayQL, PlayDBMS

[Database Administrator]

I started a new thread and waited in vain for google to allow me to
post follow-ups to the first post, so I am putting the follow-ups here
temporarily. Pls review and try to reply to the other thread titled
PlayDB. Thanks.
===
Hi,

The name 'PlayDB' is an attempt to flame-proof the thread from
comments like, "Hey, this is not the way to develop something
_serious_" Afterall, its only PlayDB!

Going through thread archives on the three groups (and sites like
dbdebunk.com) I find that a lot of arguments occur over definitiona of
basic things like "relational", "data model", etc. MySQL may use
"relational" to mean "able to process SQL queries" and the authors of
the third manifesto may mean someone else. All should be well as long
as each speaker explains his usage of each word. Words tend to be
overloaded in real life and if the multiple meanings contiue long
enough, they become the right meanings *sigh*.

I have found these online glossaries/dictionaries to be particularly
interesting, but I would like to know your opinions:
Ibm glossary of computing terms:
http://www-3.ibm.com/ibm/terminology/goc/gocmain.htm
American National Standard Dictionary for Information Systems:
http://www.ncits.org/tc_home/k5htm/ANSDIT.htm

Please point me to any other sources of information. Its easy to miss
some things when there are millions of pages to search, despite google
assistance.

I believe at the beginning of the process it might be difficult to
separate between descriptions of the model, the language, and the
implementation because they affect each other so much but eventualy it
should happen.

Regards,

Seun Osewa


====

Hi,

The architecture I have been thinking of involves storing both the
data and the business logic on the server. "Users" never actually use
the query language (Let's call it PL/PlayQL, which would be
procedural) directly. They instead connect to the PL/PlayQL programs
running on the server, via a simple request/response interface.

The language, while strictly procedural, would include a savepoints
feature that will allow the server to roll back execution in the case
of mysterious errors and try again from last savepoint. SO the
effects of program execution can always be reversed until a savepoint.
And because the program is managed by the server the programs do not
stop running abruptly when clients disconnect. In fact one can have
long-running processes on the server and it becomes something like an
OS (pending: unfuzzification of these statements).

Summary: processes using "PL/PlayQL" running on database server having
flexible access to data. Client programs connect to these processes
and communicate using simplified protocols that are totally
independent of the underlying database. All business logic is
implemented on the server. PL/PlayQL as a language implements
savepoints and can be rolled back to last savepoint. Communication
with client actually takes place at savepoint boundaries (cause it
cannot be reversed).

Seun Osewa

====
Hi,

The name 'PlayDB' is an attempt to flame-proof the thread from
comments like, "Hey, this is not the way to develop something
_serious_" Afterall, its only PlayDB!

Going through thread archives on the three groups (and sites like
dbdebunk.com) I find that a lot of arguments occur over definitiona of
basic things like "relational", "data model", etc. MySQL may use
"relational" to mean "able to process SQL queries" and the authors of
the third manifesto may mean someone else. All should be well as long
as each speaker explains his usage of each word. Words tend to be
overloaded in real life and if the multiple meanings contiue long
enough, they become the right meanings *sigh*.

I have found these online glossaries/dictionaries to be particularly
interesting, but I would like to know your opinions:
Ibm glossary of computing terms:
http://www-3.ibm.com/ibm/terminology/goc/gocmain.htm
American National Standard Dictionary for Information Systems:
http://www.ncits.org/tc_home/k5htm/ANSDIT.htm

Please point me to any other sources of information. Its easy to miss
some things when there are millions of pages to search, despite google
assistance.

I believe at the beginning of the process it might be difficult to
separate between descriptions of the model, the language, and the
implementation because they affect each other so much but eventualy it
should happen.

Regards,

Seun Osewa


====

Hi,

The architecture I have been thinking of involves storing both the
data and the business logic on the server. "Users" never actually use
the query language (Let's call it PL/PlayQL, which would be
procedural) directly. They instead connect to the PL/PlayQL programs
running on the server, via a simple request/response interface.

The language, while strictly procedural, would include a savepoints
feature that will allow the server to roll back execution in the case
of mysterious errors and try again from last savepoint. SO the
effects of program execution can always be reversed until a savepoint.
And because the program is managed by the server the programs do not
stop running abruptly when clients disconnect. In fact one can have
long-running processes on the server and it becomes something like an
OS (pending: unfuzzification of these statements).

Summary: processes using "PL/PlayQL" running on database server having
flexible access to data. Client programs connect to these processes
and communicate using simplified protocols that are totally
independent of the underlying database. All business logic is
implemented on the server. PL/PlayQL as a language implements
savepoints and can be rolled back to last savepoint. Communication
with client actually takes place at savepoint boundaries (cause it
cannot be reversed).

Seun Osewa
====
Hi,

I am thinking of some non-standard definitions for the PlayDB system:

Data Model: a way of representing reality in an information system so
it can be usefully manipulated.

Object: An independent entity, distingushable from all other objects
by a certain unique combination of attributes.

Class: (Most Important)Any arbitrary group of objects thought to
possess certain similarities. And the special thought here is that
classes may overlap in interesting ways.

For example: a=rectangle, b=square, c=paralellogram, d=rhombus
rectangle = (a,b)
parallelogram = (a,b,c,d)
rhombus=(b,d)

This represents no hierarchy. That's why I want to see it as
arbitrary grouping.

Seun Osewa


seunosewa@inaira.com (Seun Osewa) wrote in message news:...
> Hi,
>
> This is for relational database theory experts on one hand and
> imlementers of real-world alications on the other hand. If there was
> a chance to start again and design SQL afresh, for best
> cleaness/power/performance what changes would you make? What would
> _your_ query language (and the underlying database concept) look like?
>
> Seun Osewa
> PS: I should want to post my ideas too for review but more
> experienced/qualified people should come first

[Database Administrator]

With all due respect, relational means something very specific when it comes
to database management just as rational has a very specific meaning when
talking about numeric algebras.

"Seun Osewa" wrote in message
news:ba87a3cf.0310091647.5c788fad@posting.google.c om...
> I started a new thread and waited in vain for google to allow me to
> post follow-ups to the first post, so I am putting the follow-ups here
> temporarily. Pls review and try to reply to the other thread titled
> PlayDB. Thanks.
> ===
> Hi,
>
> The name 'PlayDB' is an attempt to flame-proof the thread from
> comments like, "Hey, this is not the way to develop something
> _serious_" Afterall, its only PlayDB!
>
> Going through thread archives on the three groups (and sites like
> dbdebunk.com) I find that a lot of arguments occur over definitiona of
> basic things like "relational", "data model", etc. MySQL may use
> "relational" to mean "able to process SQL queries" and the authors of
> the third manifesto may mean someone else. All should be well as long
> as each speaker explains his usage of each word. Words tend to be
> overloaded in real life and if the multiple meanings contiue long
> enough, they become the right meanings *sigh*.
>
> I have found these online glossaries/dictionaries to be particularly
> interesting, but I would like to know your opinions:
> Ibm glossary of computing terms:
> http://www-3.ibm.com/ibm/terminology/goc/gocmain.htm
> American National Standard Dictionary for Information Systems:
> http://www.ncits.org/tc_home/k5htm/ANSDIT.htm
>
> Please point me to any other sources of information. Its easy to miss
> some things when there are millions of pages to search, despite google
> assistance.
>
> I believe at the beginning of the process it might be difficult to
> separate between descriptions of the model, the language, and the
> implementation because they affect each other so much but eventualy it
> should happen.
>
> Regards,
>
> Seun Osewa
>
>
> ====
>
> Hi,
>
> The architecture I have been thinking of involves storing both the
> data and the business logic on the server. "Users" never actually use
> the query language (Let's call it PL/PlayQL, which would be
> procedural) directly. They instead connect to the PL/PlayQL programs
> running on the server, via a simple request/response interface.
>
> The language, while strictly procedural, would include a savepoints
> feature that will allow the server to roll back execution in the case
> of mysterious errors and try again from last savepoint. SO the
> effects of program execution can always be reversed until a savepoint.
> And because the program is managed by the server the programs do not
> stop running abruptly when clients disconnect. In fact one can have
> long-running processes on the server and it becomes something like an
> OS (pending: unfuzzification of these statements).
>
> Summary: processes using "PL/PlayQL" running on database server having
> flexible access to data. Client programs connect to these processes
> and communicate using simplified protocols that are totally
> independent of the underlying database. All business logic is
> implemented on the server. PL/PlayQL as a language implements
> savepoints and can be rolled back to last savepoint. Communication
> with client actually takes place at savepoint boundaries (cause it
> cannot be reversed).
>
> Seun Osewa
>
> ====
> Hi,
>
> The name 'PlayDB' is an attempt to flame-proof the thread from
> comments like, "Hey, this is not the way to develop something
> _serious_" Afterall, its only PlayDB!
>
> Going through thread archives on the three groups (and sites like
> dbdebunk.com) I find that a lot of arguments occur over definitiona of
> basic things like "relational", "data model", etc. MySQL may use
> "relational" to mean "able to process SQL queries" and the authors of
> the third manifesto may mean someone else. All should be well as long
> as each speaker explains his usage of each word. Words tend to be
> overloaded in real life and if the multiple meanings contiue long
> enough, they become the right meanings *sigh*.
>
> I have found these online glossaries/dictionaries to be particularly
> interesting, but I would like to know your opinions:
> Ibm glossary of computing terms:
> http://www-3.ibm.com/ibm/terminology/goc/gocmain.htm
> American National Standard Dictionary for Information Systems:
> http://www.ncits.org/tc_home/k5htm/ANSDIT.htm
>
> Please point me to any other sources of information. Its easy to miss
> some things when there are millions of pages to search, despite google
> assistance.
>
> I believe at the beginning of the process it might be difficult to
> separate between descriptions of the model, the language, and the
> implementation because they affect each other so much but eventualy it
> should happen.
>
> Regards,
>
> Seun Osewa
>
>
> ====
>
> Hi,
>
> The architecture I have been thinking of involves storing both the
> data and the business logic on the server. "Users" never actually use
> the query language (Let's call it PL/PlayQL, which would be
> procedural) directly. They instead connect to the PL/PlayQL programs
> running on the server, via a simple request/response interface.
>
> The language, while strictly procedural, would include a savepoints
> feature that will allow the server to roll back execution in the case
> of mysterious errors and try again from last savepoint. SO the
> effects of program execution can always be reversed until a savepoint.
> And because the program is managed by the server the programs do not
> stop running abruptly when clients disconnect. In fact one can have
> long-running processes on the server and it becomes something like an
> OS (pending: unfuzzification of these statements).
>
> Summary: processes using "PL/PlayQL" running on database server having
> flexible access to data. Client programs connect to these processes
> and communicate using simplified protocols that are totally
> independent of the underlying database. All business logic is
> implemented on the server. PL/PlayQL as a language implements
> savepoints and can be rolled back to last savepoint. Communication
> with client actually takes place at savepoint boundaries (cause it
> cannot be reversed).
>
> Seun Osewa
> ====
> Hi,
>
> I am thinking of some non-standard definitions for the PlayDB system:
>
> Data Model: a way of representing reality in an information system so
> it can be usefully manipulated.
>
> Object: An independent entity, distingushable from all other objects
> by a certain unique combination of attributes.
>
> Class: (Most Important)Any arbitrary group of objects thought to
> possess certain similarities. And the special thought here is that
> classes may overlap in interesting ways.
>
> For example: a=rectangle, b=square, c=paralellogram, d=rhombus
> rectangle = (a,b)
> parallelogram = (a,b,c,d)
> rhombus=(b,d)
>
> This represents no hierarchy. That's why I want to see it as
> arbitrary grouping.
>
> Seun Osewa
>
>
> seunosewa@inaira.com (Seun Osewa) wrote in message
news:...
> > Hi,
> >
> > This is for relational database theory experts on one hand and
> > imlementers of real-world alications on the other hand. If there was
> > a chance to start again and design SQL afresh, for best
> > cleaness/power/performance what changes would you make? What would
> > _your_ query language (and the underlying database concept) look like?
> >
> > Seun Osewa
> > PS: I should want to post my ideas too for review but more
> > experienced/qualified people should come first

[Database Administrator]

With all due respect, relational means something very specific when it comes
to database management just as rational has a very specific meaning when
talking about numeric algebras.

"Seun Osewa" wrote in message
news:ba87a3cf.0310091647.5c788fad@posting.google.c om...
> I started a new thread and waited in vain for google to allow me to
> post follow-ups to the first post, so I am putting the follow-ups here
> temporarily. Pls review and try to reply to the other thread titled
> PlayDB. Thanks.
> ===
> Hi,
>
> The name 'PlayDB' is an attempt to flame-proof the thread from
> comments like, "Hey, this is not the way to develop something
> _serious_" Afterall, its only PlayDB!
>
> Going through thread archives on the three groups (and sites like
> dbdebunk.com) I find that a lot of arguments occur over definitiona of
> basic things like "relational", "data model", etc. MySQL may use
> "relational" to mean "able to process SQL queries" and the authors of
> the third manifesto may mean someone else. All should be well as long
> as each speaker explains his usage of each word. Words tend to be
> overloaded in real life and if the multiple meanings contiue long
> enough, they become the right meanings *sigh*.
>
> I have found these online glossaries/dictionaries to be particularly
> interesting, but I would like to know your opinions:
> Ibm glossary of computing terms:
> http://www-3.ibm.com/ibm/terminology/goc/gocmain.htm
> American National Standard Dictionary for Information Systems:
> http://www.ncits.org/tc_home/k5htm/ANSDIT.htm
>
> Please point me to any other sources of information. Its easy to miss
> some things when there are millions of pages to search, despite google
> assistance.
>
> I believe at the beginning of the process it might be difficult to
> separate between descriptions of the model, the language, and the
> implementation because they affect each other so much but eventualy it
> should happen.
>
> Regards,
>
> Seun Osewa
>
>
> ====
>
> Hi,
>
> The architecture I have been thinking of involves storing both the
> data and the business logic on the server. "Users" never actually use
> the query language (Let's call it PL/PlayQL, which would be
> procedural) directly. They instead connect to the PL/PlayQL programs
> running on the server, via a simple request/response interface.
>
> The language, while strictly procedural, would include a savepoints
> feature that will allow the server to roll back execution in the case
> of mysterious errors and try again from last savepoint. SO the
> effects of program execution can always be reversed until a savepoint.
> And because the program is managed by the server the programs do not
> stop running abruptly when clients disconnect. In fact one can have
> long-running processes on the server and it becomes something like an
> OS (pending: unfuzzification of these statements).
>
> Summary: processes using "PL/PlayQL" running on database server having
> flexible access to data. Client programs connect to these processes
> and communicate using simplified protocols that are totally
> independent of the underlying database. All business logic is
> implemented on the server. PL/PlayQL as a language implements
> savepoints and can be rolled back to last savepoint. Communication
> with client actually takes place at savepoint boundaries (cause it
> cannot be reversed).
>
> Seun Osewa
>
> ====
> Hi,
>
> The name 'PlayDB' is an attempt to flame-proof the thread from
> comments like, "Hey, this is not the way to develop something
> _serious_" Afterall, its only PlayDB!
>
> Going through thread archives on the three groups (and sites like
> dbdebunk.com) I find that a lot of arguments occur over definitiona of
> basic things like "relational", "data model", etc. MySQL may use
> "relational" to mean "able to process SQL queries" and the authors of
> the third manifesto may mean someone else. All should be well as long
> as each speaker explains his usage of each word. Words tend to be
> overloaded in real life and if the multiple meanings contiue long
> enough, they become the right meanings *sigh*.
>
> I have found these online glossaries/dictionaries to be particularly
> interesting, but I would like to know your opinions:
> Ibm glossary of computing terms:
> http://www-3.ibm.com/ibm/terminology/goc/gocmain.htm
> American National Standard Dictionary for Information Systems:
> http://www.ncits.org/tc_home/k5htm/ANSDIT.htm
>
> Please point me to any other sources of information. Its easy to miss
> some things when there are millions of pages to search, despite google
> assistance.
>
> I believe at the beginning of the process it might be difficult to
> separate between descriptions of the model, the language, and the
> implementation because they affect each other so much but eventualy it
> should happen.
>
> Regards,
>
> Seun Osewa
>
>
> ====
>
> Hi,
>
> The architecture I have been thinking of involves storing both the
> data and the business logic on the server. "Users" never actually use
> the query language (Let's call it PL/PlayQL, which would be
> procedural) directly. They instead connect to the PL/PlayQL programs
> running on the server, via a simple request/response interface.
>
> The language, while strictly procedural, would include a savepoints
> feature that will allow the server to roll back execution in the case
> of mysterious errors and try again from last savepoint. SO the
> effects of program execution can always be reversed until a savepoint.
> And because the program is managed by the server the programs do not
> stop running abruptly when clients disconnect. In fact one can have
> long-running processes on the server and it becomes something like an
> OS (pending: unfuzzification of these statements).
>
> Summary: processes using "PL/PlayQL" running on database server having
> flexible access to data. Client programs connect to these processes
> and communicate using simplified protocols that are totally
> independent of the underlying database. All business logic is
> implemented on the server. PL/PlayQL as a language implements
> savepoints and can be rolled back to last savepoint. Communication
> with client actually takes place at savepoint boundaries (cause it
> cannot be reversed).
>
> Seun Osewa
> ====
> Hi,
>
> I am thinking of some non-standard definitions for the PlayDB system:
>
> Data Model: a way of representing reality in an information system so
> it can be usefully manipulated.
>
> Object: An independent entity, distingushable from all other objects
> by a certain unique combination of attributes.
>
> Class: (Most Important)Any arbitrary group of objects thought to
> possess certain similarities. And the special thought here is that
> classes may overlap in interesting ways.
>
> For example: a=rectangle, b=square, c=paralellogram, d=rhombus
> rectangle = (a,b)
> parallelogram = (a,b,c,d)
> rhombus=(b,d)
>
> This represents no hierarchy. That's why I want to see it as
> arbitrary grouping.
>
> Seun Osewa
>
>
> seunosewa@inaira.com (Seun Osewa) wrote in message
news:...
> > Hi,
> >
> > This is for relational database theory experts on one hand and
> > imlementers of real-world alications on the other hand. If there was
> > a chance to start again and design SQL afresh, for best
> > cleaness/power/performance what changes would you make? What would
> > _your_ query language (and the underlying database concept) look like?
> >
> > Seun Osewa
> > PS: I should want to post my ideas too for review but more
> > experienced/qualified people should come first

[Database Administrator]

With all due respect, relational means something very specific when it comes
to database management just as rational has a very specific meaning when
talking about numeric algebras.

"Seun Osewa" wrote in message
news:ba87a3cf.0310091647.5c788fad@posting.google.c om...
> I started a new thread and waited in vain for google to allow me to
> post follow-ups to the first post, so I am putting the follow-ups here
> temporarily. Pls review and try to reply to the other thread titled
> PlayDB. Thanks.
> ===
> Hi,
>
> The name 'PlayDB' is an attempt to flame-proof the thread from
> comments like, "Hey, this is not the way to develop something
> _serious_" Afterall, its only PlayDB!
>
> Going through thread archives on the three groups (and sites like
> dbdebunk.com) I find that a lot of arguments occur over definitiona of
> basic things like "relational", "data model", etc. MySQL may use
> "relational" to mean "able to process SQL queries" and the authors of
> the third manifesto may mean someone else. All should be well as long
> as each speaker explains his usage of each word. Words tend to be
> overloaded in real life and if the multiple meanings contiue long
> enough, they become the right meanings *sigh*.
>
> I have found these online glossaries/dictionaries to be particularly
> interesting, but I would like to know your opinions:
> Ibm glossary of computing terms:
> http://www-3.ibm.com/ibm/terminology/goc/gocmain.htm
> American National Standard Dictionary for Information Systems:
> http://www.ncits.org/tc_home/k5htm/ANSDIT.htm
>
> Please point me to any other sources of information. Its easy to miss
> some things when there are millions of pages to search, despite google
> assistance.
>
> I believe at the beginning of the process it might be difficult to
> separate between descriptions of the model, the language, and the
> implementation because they affect each other so much but eventualy it
> should happen.
>
> Regards,
>
> Seun Osewa
>
>
> ====
>
> Hi,
>
> The architecture I have been thinking of involves storing both the
> data and the business logic on the server. "Users" never actually use
> the query language (Let's call it PL/PlayQL, which would be
> procedural) directly. They instead connect to the PL/PlayQL programs
> running on the server, via a simple request/response interface.
>
> The language, while strictly procedural, would include a savepoints
> feature that will allow the server to roll back execution in the case
> of mysterious errors and try again from last savepoint. SO the
> effects of program execution can always be reversed until a savepoint.
> And because the program is managed by the server the programs do not
> stop running abruptly when clients disconnect. In fact one can have
> long-running processes on the server and it becomes something like an
> OS (pending: unfuzzification of these statements).
>
> Summary: processes using "PL/PlayQL" running on database server having
> flexible access to data. Client programs connect to these processes
> and communicate using simplified protocols that are totally
> independent of the underlying database. All business logic is
> implemented on the server. PL/PlayQL as a language implements
> savepoints and can be rolled back to last savepoint. Communication
> with client actually takes place at savepoint boundaries (cause it
> cannot be reversed).
>
> Seun Osewa
>
> ====
> Hi,
>
> The name 'PlayDB' is an attempt to flame-proof the thread from
> comments like, "Hey, this is not the way to develop something
> _serious_" Afterall, its only PlayDB!
>
> Going through thread archives on the three groups (and sites like
> dbdebunk.com) I find that a lot of arguments occur over definitiona of
> basic things like "relational", "data model", etc. MySQL may use
> "relational" to mean "able to process SQL queries" and the authors of
> the third manifesto may mean someone else. All should be well as long
> as each speaker explains his usage of each word. Words tend to be
> overloaded in real life and if the multiple meanings contiue long
> enough, they become the right meanings *sigh*.
>
> I have found these online glossaries/dictionaries to be particularly
> interesting, but I would like to know your opinions:
> Ibm glossary of computing terms:
> http://www-3.ibm.com/ibm/terminology/goc/gocmain.htm
> American National Standard Dictionary for Information Systems:
> http://www.ncits.org/tc_home/k5htm/ANSDIT.htm
>
> Please point me to any other sources of information. Its easy to miss
> some things when there are millions of pages to search, despite google
> assistance.
>
> I believe at the beginning of the process it might be difficult to
> separate between descriptions of the model, the language, and the
> implementation because they affect each other so much but eventualy it
> should happen.
>
> Regards,
>
> Seun Osewa
>
>
> ====
>
> Hi,
>
> The architecture I have been thinking of involves storing both the
> data and the business logic on the server. "Users" never actually use
> the query language (Let's call it PL/PlayQL, which would be
> procedural) directly. They instead connect to the PL/PlayQL programs
> running on the server, via a simple request/response interface.
>
> The language, while strictly procedural, would include a savepoints
> feature that will allow the server to roll back execution in the case
> of mysterious errors and try again from last savepoint. SO the
> effects of program execution can always be reversed until a savepoint.
> And because the program is managed by the server the programs do not
> stop running abruptly when clients disconnect. In fact one can have
> long-running processes on the server and it becomes something like an
> OS (pending: unfuzzification of these statements).
>
> Summary: processes using "PL/PlayQL" running on database server having
> flexible access to data. Client programs connect to these processes
> and communicate using simplified protocols that are totally
> independent of the underlying database. All business logic is
> implemented on the server. PL/PlayQL as a language implements
> savepoints and can be rolled back to last savepoint. Communication
> with client actually takes place at savepoint boundaries (cause it
> cannot be reversed).
>
> Seun Osewa
> ====
> Hi,
>
> I am thinking of some non-standard definitions for the PlayDB system:
>
> Data Model: a way of representing reality in an information system so
> it can be usefully manipulated.
>
> Object: An independent entity, distingushable from all other objects
> by a certain unique combination of attributes.
>
> Class: (Most Important)Any arbitrary group of objects thought to
> possess certain similarities. And the special thought here is that
> classes may overlap in interesting ways.
>
> For example: a=rectangle, b=square, c=paralellogram, d=rhombus
> rectangle = (a,b)
> parallelogram = (a,b,c,d)
> rhombus=(b,d)
>
> This represents no hierarchy. That's why I want to see it as
> arbitrary grouping.
>
> Seun Osewa
>
>
> seunosewa@inaira.com (Seun Osewa) wrote in message
news:...
> > Hi,
> >
> > This is for relational database theory experts on one hand and
> > imlementers of real-world alications on the other hand. If there was
> > a chance to start again and design SQL afresh, for best
> > cleaness/power/performance what changes would you make? What would
> > _your_ query language (and the underlying database concept) look like?
> >
> > Seun Osewa
> > PS: I should want to post my ideas too for review but more
> > experienced/qualified people should come first

[Database Administrator]

A long time ago, in a galaxy far, far away, seunosewa@inaira.com (Seun Osewa) wrote:
> I started a new thread and waited in vain for google to allow me to
> post follow-ups to the first post, so I am putting the follow-ups here
> temporarily. Pls review and try to reply to the other thread titled
> PlayDB. Thanks.

This is NOT something where it is likely that structure can emerge out
of the chaos of a series of Usenet postings.

Designing a model for data access is a matter that requires an
enormous amount of thought and reflection, and mandates having a clear
crystal of an idea. Crystals need to be left undisturbed until they
have grown to size; that is doubtless true here.

The "committee" approach is what led to the characteristic _problems_
of SQL, where competing agendas assortedly led to:
a) Necessary features being left out because they couldn't agree
on them [SQL '99 finally got around to having the notion of
'sequences']
b) Stuff getting forced in on the basis of political pressure.

Your "chance" of coming up with a design depends on carefully defining
a design, and presenting it coherently. But the chaos of Usenet is
unlikely to be the right place for that.
--
wm(X,Y):-write(X),write('@'),write(Y). wm('cbbrowne','acm.org').
http://www.ntlug.org/~cbbrowne/unix.html
Dain bramaged.

[Database Administrator]

A long time ago, in a galaxy far, far away, seunosewa@inaira.com (Seun Osewa) wrote:
> I started a new thread and waited in vain for google to allow me to
> post follow-ups to the first post, so I am putting the follow-ups here
> temporarily. Pls review and try to reply to the other thread titled
> PlayDB. Thanks.

This is NOT something where it is likely that structure can emerge out
of the chaos of a series of Usenet postings.

Designing a model for data access is a matter that requires an
enormous amount of thought and reflection, and mandates having a clear
crystal of an idea. Crystals need to be left undisturbed until they
have grown to size; that is doubtless true here.

The "committee" approach is what led to the characteristic _problems_
of SQL, where competing agendas assortedly led to:
a) Necessary features being left out because they couldn't agree
on them [SQL '99 finally got around to having the notion of
'sequences']
b) Stuff getting forced in on the basis of political pressure.

Your "chance" of coming up with a design depends on carefully defining
a design, and presenting it coherently. But the chaos of Usenet is
unlikely to be the right place for that.
--
wm(X,Y):-write(X),write('@'),write(Y). wm('cbbrowne','acm.org').
http://www.ntlug.org/~cbbrowne/unix.html
Dain bramaged.

[Database Administrator]

A long time ago, in a galaxy far, far away, seunosewa@inaira.com (Seun Osewa) wrote:
> I started a new thread and waited in vain for google to allow me to
> post follow-ups to the first post, so I am putting the follow-ups here
> temporarily. Pls review and try to reply to the other thread titled
> PlayDB. Thanks.

This is NOT something where it is likely that structure can emerge out
of the chaos of a series of Usenet postings.

Designing a model for data access is a matter that requires an
enormous amount of thought and reflection, and mandates having a clear
crystal of an idea. Crystals need to be left undisturbed until they
have grown to size; that is doubtless true here.

The "committee" approach is what led to the characteristic _problems_
of SQL, where competing agendas assortedly led to:
a) Necessary features being left out because they couldn't agree
on them [SQL '99 finally got around to having the notion of
'sequences']
b) Stuff getting forced in on the basis of political pressure.

Your "chance" of coming up with a design depends on carefully defining
a design, and presenting it coherently. But the chaos of Usenet is
unlikely to be the right place for that.
--
wm(X,Y):-write(X),write('@'),write(Y). wm('cbbrowne','acm.org').
http://www.ntlug.org/~cbbrowne/unix.html
Dain bramaged.