Re: Introducing PlayDB (The Model, The Language, The DBMS)

Hi,

In response to Bob Badour:
> When proposing a new data model, one must address the issues of data
> independence, semantic expressibility, referential integrity and data
> manipulation among others.
Believe me I am working on it one step at a time. And also learning a lot of new phrases. And being sharpened up, I hope. This is why I am taking this approach of posting openly. This is work in progress and I appreciate you helping me figure out some relevant next steps

"Referential Integrity": Each pointer-to-object has a single class of objects it is allowed to point to and on being pointed at a new object checks are made to see that the the object being pointed to is a member  of the required class, at least.

"Semantic Expressibility": I assume you mean the ability to specify suitably complex queries to the DBMS, right? Working on the query language. Will post some thoughts about this soon.

"Data Independence": The separation of data from the programs that use the data. (http://www.pcwebopaedia.com/TERM/D/data_independence.html) Why? So that both programs and the data can be changed independently of each other. But in reality data consists not only of simple constant  attributes like 'Seun's Birthdate'. It may also consist of algorithms like "formular for tax calculation in 1993 November". I suggest this is one reason why "enterprise" databases end up with a lot of stored procedures and triggers. So what I am suggesting is a suitably smart server-side query/procedural language (may include OO code organisation features) which provides access to the database and which is used to build long-running processes on the server which connect to client programs through applicationspecific  protocols which need not change for the lifetime of the application even though the 'database' is changing.

What I have done here is: to split "application" into two. Take the business logic which is really inseparable from the database way and move it into 'server-side'. Put the presentation logic in 'client-side'. Define an app-specific communication protocol As long as the protocols are adhered to I have separation of 'server-side' and 'client-side' which is really what we wanted in the first case if I am not mistaken. Which is what "enterprise" applications are attempting to do with 3-tier designs and extensive  stored procedure libraries.

"Data Manipulation": ... I guess once I start to talk about the query language the possibilities will become clearer. I would not agree that my proposed scheme is "typeless". i'd rather say it has dynamic typing. How exactly attributes of the objects will be exported to each interface i have no idea but I am looking  into the implementation of OO "interfaces" for inspiration. One advantage I may have is the intended support for algorithms in the database. Then such algorithms may be used to read or write data from a given object being considered as being a member  of a particular class.

He also wrote:
>>One implication of this is that object creation queries will not be of
>>the form INSERT RELATION_XXX SET ATTRIBUTE = .... Instead it will be
>>like CREATE OBJECT WITH ATTRIBUTES .... ... ... [MEMBER OF CLASSES
>>PPP, QQQ, RRR]. <me>
>This is non sequitur. The former does not imply the latter. All you have
>done with the latter is remove the ability to express n-ary relations among
>values and impose a huge cognitive burden on users who must know the full
>set of types they want each value to have.
Users do not need to know all the types. As I said the admin can simulate a hierarchy or "DAG" type structure by creating constraints that automatically  add an object to a class if the user specifies it to belong to what the DBA sees as a subtype. In PlayDB Proposal 1(heh) the concept of type inheritance or relationship between classes is wholly in the mind of the DBA and is enforced by constraints which can be relaxed at a later date if need be. i still think its a smart concept if one ignores implementation issues.

And also:
>>Objects are inserted into "the system" and not into
>>tables.
>Thereby crippling the system. Without relations, all one has is a
>hodge-podge of disjoint values without any means to derive new facts
>from them.
Please tell me exactly what sort of facts cannot be derived and I will try to explain how in fact they can be derived. The devilish part will be the implementation. Already studying adaptive block rearrangement and log structured data storage for possible answers. I apologize in advance that thought about the implementation may tend to affect discussions  about the model: if two approaches are equally powerful but one seems easier to implement its natural to choose the one that's going to be easier to implement cause IMHO an unworkable model is useless.

What do you think? I like the idea that my spontaneous presentation gets to be dissected line by line.

Best regards,
Seun Osewa Received on Fri Oct 10 2003 - 18:01:56 CEST