Re: The same simple question to relational theorist (with video now).

> The query results in your examples often show empty cells. If their contents are something like NULL, then no, your system can almost by definition not be relational.

1. E.g. in http://www.dcs.warwick.ac.uk/~hugh/TTM/Missing-info-without-nulls.pdf on page 7 there is a question "BUT WHAT DO THOSE QUESTION MARKS MEAN?". I don't try to go in meaning of the empty cell so deeply. It's just empty cells. 2)I could say that an implementation of my solution is as relational as using executive machine is. If we are using "true relational" system as executive machine the result will be perfect theoretically. If we are using SQL DBMS the result will possible contains NULL, dublicates etc. Offered principles can be applied to both "true" and "not true" relational systems.
2. 3-valued SQL logic is a very old question. It's intrestiong question but it's not principial for me. My solution could appear 25 years back on that level of relational theory and OO programing. For me a most hard thing was to forget about all complicated things and ideas which appeared since that time.

> The system seems to be based on hierarchies of classes. That makes me wonder about situations where there are self-references (boss of employee3 is employee2, boss of employee2 is employee7, ...) and transitive closures in the processing.

I dont' implement transitive closures cases in the prototype. Common idea looks like

CREATE CLASS EMPLOYEE
{
  name...;
}

CREATE CLASS BOSS EXTENDS EMPLOYEE
{
  employees SET OF EMPLOYEE;
}

SELECT #b.employees.name FROM BOSS #b... THROUGH #b.employees... DOWN #b.name="MainBoss"

   //"THROUGH" checks if some of "b.employees" are BOSSes 
   //       and executes SELECT again for found ones.
   // "DOWN" sets "starting point" in BOSS'es hierarchy.

This query returns names of all employee under "MainBoss". (Don't be strict it's just a concept:)  

> I'm wondering how transactions/commit/rollback fit into the system. If there is "autocommit" upon each NEW GOODS() executed, then I wonder about the situations that require SQL users to switch over to deferred constraint checking. (And if there is no possibility to declare constraints, then no, what you've created is not worth being called a DBMS. But I rather doubt this is the case.)

1. Transaction is not a question between OO and RM. :)
2. I don't understand what does "deferred constraints" mean here.
3. I gave an examples of constrains in video (from ~4:00). Could you explaym your question in more details with these contrains if it's possible?

> You also use the term "inheritance" in connection with your classes, but it is unclear to me what "inheritance" really means here, or how it could be useful to me as a user of this system.

Object domain can change and, according to the changes, you can create new classes (inc. by multiple inheritance) in active DBMS. There is no necessity to rebuild, recompile, reload and make other re- over system in this case, just create new class and you can use it with existing ones. You could see the video after 19 min once again. I gave an example of how the system can be extended by means of multiple inheritance. Received on Sun May 05 2013 - 19:02:26 CEST