Re: Nulls, integrity, the closed world assumption and events

Keith H Duggar wrote:
> dawn wrote:
> > Walt wrote:
> > > Many have attempted, but you have been expounding on the same incorrect
> > > ideas for something like five years now.
> >
> > Could you point me to proof that something I expound is incorrect?
> > Perhaps just starting by telling me what I think to be true that you
> > think false, or vice versa, would be helpful. I would very much
> > appreciate knowing.
>
> RM != SQL
> QED
>
> Keith -- Fraud 6

Hi Keith - I do not equate RM with SQL. I do think, however, that we would not have SQL were it not for the RM. The RM could be seen as a primary "culprit" in giving us SQL. Additionally, most, if not all, implementations that are based on the relational model employ SQL as the means of interacting with the DBMS. Marketing and other materials for a couple of decades now use the acronym RDBMS when referring to SQL-DBMS's for good reason.

So, I agree that RM != SQL, but when I started investigating developer productivity and differences in data models for stored (persisted) data, I traced the history back to the point where it appeared that we, as a discipline, introduced some significant technology that drastically reduced developer productivity (unnecessarily, in my opinion) for developers creating or maintaining data-based software. That technology included SQL and was based on the relational model.

Products such as DB2 are taking some drastic measures to attempt to retain SQL and still move forward with more flexible data models. However, I suspect that the industry really needs to ditch at least three (maybe more) aspects of SQL, all of which stemmed from the RM originally. 1) 1NF as taught in many college database courses from the 80's even to today 2) insistence on unorderedness, i.e. lack of lists and ordered "tables" and 3) 3VL.

I now understand that many RM folks agree with at least 1) & 3) and permit 2) as a user-defined type (which doesn't integrate with any existing RM-based query language, as best I can tell). It doesn't appear to me that changes to the RM will be the fastest way to get to where we need to be, however. I think we need to come up with some better understanding of and appreciation for a "wiki" or "web" data model, one that pre-dates the RM. Because it has been around for many years, there should be some good emperical data regarding the use of this model compared to the RM, but I have not seen it. I do know that many of the tools that have employed it have suffered from RM-as-king-of-the-hill syndrome (which is where the SQL-DBMS's come in, and, no, I'm still not equating the RM with SQL), and might not be where they need to be for developer tools and standard APIs.

It appears that the DBMS world is headed back (or going to head back) to the wiki data model (di-graph with trees on the nodes). We need to accept both set-based functions and tree traversal (navigation, if you like) before we get there. But this threatens set-based constraints, as well as the form formerly known as 1NF and 3VL, where there is a huge installed base.

I have no doubt that we will be working with DBMS tools that have attempted to implement the RM, using SQL in their efforts, for many years. Although I'm sure I have plenty to learn on the theory side, I'm to the point where I know that I would like to see the data-based software development industry improve productivity by moving beyond the mistakes or poor choices that came from the introduction of the RM, and subsequent implementations of SQL, sooner rather than later, still recognizing that the RM != SQL.

Did that clarify? Is there anything with which you disagree? --dawn Received on Mon Jan 22 2007 - 01:38:54 CET