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" <seunosewa_at_inaira.com> wrote in message
news:ba87a3cf.0310091647.5c788fad_at_posting.google.com...
> 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_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 Thu Oct 09 2003 - 21:31:23 CDT
