1GB Tables as Classes, or Tables as Types, and all that refuted

In The Third Manifesto, D&D affirm that 'tis a great blunder to equate "classes" with relations or with relation variables. Some people still believe that, although the riguorous proof of the drastic consequences supposed to follow is completely lacking.

So here's a direct positive refutation, including with inheritance( well that maybe later, as it is orthogonal).

Say the minimal common entity (in case you don't believe an ERD, a set of attributes that are grouped together in a base relvar) is a User.

Most systems have an users table:
USERS( user_id, username, password, email )

where user_id is UNIQUE NOT NULL, and the same is USERNAME.

Most of the client programmers, be it in Java, C++, whatever, create a User class with respective attributes. The reason for that is simply manageability and economy of expression. You do not want to carry around 4 variables, namely userID, userName, password, email, to do some processing (even if just displaying on an output device) when you can simple manipulate just 1 variable and that be user.

if that was a blunder, we'd all be suffering terrible consequences, but we don't, and even if that wasn't a proof enough in itself, let's consider how we should do it:

if we have a User(userID,username, password, email) TYPE, than that type is a domain, and we should store it inside the database only within a column.

So voila we have a UsersTable( user : User) table. of course the primary key would be now constructed on the expression user.userID rather than ona set of direct attributes, and so the other uniqueness constraint would be on user.username rather than on a set of attributes.

But then since we have the deconstructors/accessors user.userID, user.userName, user.email, we can regard the table thus defined perfectly isomorphic/interchangeable (including under the strictest definition of view updates) with the view

create view UsersView as select user.userID, user.userName, user.email, user.passwor from UsersTable

Because they are so obviously interchangeable with regards to all relational operators as well as with regards to updates, if one is a blunder than the other is a blunder. But one would be a blunder according to D&D and another would be prescribed according to D&D.

So the pragmatic knowledge that everybody and their grandma programming systems these days do have a Users table and do have a User class, and nothing bad happens because of this designed is directly confirmed by simple logical reasoning.

The same goes if the User information will not make up the whole table but would be just a column in a larger table. we can create the equivalent/interchangeable view table by selecting expressions on that object, as long as we have the accessor/deconstructor for attributes of the object. For example PointsTable1(x:int, y:int) <=> PointsTable2(p:Point) where Point = {x:int, y:int} as type.

In my current software system that puts food on my table I have two types of users (therefore subtyping/type unification and all that) anonymous_users and registered_users, and guess what, I have two tables for that. And it works, nevermind it's Oracle, but even if I had the perfect TutorialD database (which will never happen) my design would have been the same and would have been 100% isomorphic with a design that follows strictly D&D prescription for putting object values in one column (more formally types from OO are domains inside the relational database).

Best,
Costin

Jan Hidders wrote:
> Jonathan Leffler wrote:
>

>>
>> So, I disagree with Gittens' claimed demolition of 1GB - I do not 
>> consider that he has proved his point at all.