PlayDB, PlayQL, PlayDBMS

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

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

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_at_inaira.com (Seun Osewa) wrote in message news:<ba87a3cf.0310031052.77315052_at_posting.google.com>...
> 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
Received on Fri Oct 10 2003 - 02:47:39 CEST