Relational With Side Effects

Another way of putting it: "relational with callbacks".

A relational database with callback procedures that actually executes code to do important tasks.

http://www.mountainman.com.au/software/history/relational_model_incomplete.htm

A relational database is castrated (very limited) if it can't execute code to do tasks on a client machine. A relational database without code side effects just allows you to store dumb data and do nothing else. There are applications out there where just storing data is all you need. However what about a GUI program that interacts with the database instead interacting with an Object in OOP.

Let's take an example:

a checkbox on a GUI window
instead of the checkbox updating the object in OOP, it updates the DATABASE.
when the checkbox is clicked, it updates a boolean in the database
the database stores the "checked" property as true when checked, false when not checked
when someone updates the database and changes the checked column, it executes code to paint the GUI window widget (checkbox)
but how can the database execute code on a client's computer?
that's what OOP allows us to do.. when we change the checked property to true, it paints GUI
OOP is already on the client's machine.. objects exist together with data and methods
relational keeps data too far separate from the code, lots of annoying glue code needs to be written and lots of wasted duplication (that's what O/R mapping tries to address

Does this violate relational? relational with massive side effects? That's what OOP actually is: it allows important side effects.

The checked column is executing a callback or a side effect in order to paint the GUI window. If the boolean of the checked column is set to true, then the GUI must be painted so that the checkbox is shown checked. If the boolean of the checked column is set to false, then the GUI must repaint the gui window so that the checkbox is blank/white.

Where is this callback stored, and is any of this violating relational?

Object Orientation has side effects. When you use a checkbox object in your OOP program, as soon as you set the CHECKED property to FALSE, this executes more code as a side effect to paint the GUI. Without this extremely important side effect, the objects wouldn't be very powerful.

Many databases have stored procedures and triggers, but what does the relational model think about those?

Stored procedures and triggers still don't have access to the Win32 API on the person's screen, or the X window system, in order to update the checkbox using gui calls, Stored procedures as far as I know are really only addressing the server side of things - they can send an email if sendmail is available, for example, from the server. But what about the actual client computer executing code to update the GUI?

The way we deal with it today is to put this code in the application.

Relational is fading away into academic obscurity because it doesn't address some very important issues that OOP already addresses for us. With OOP we can execute code and have plenty of side effects, painting GUI's and doing anything we want. But with castrated limited relational databases, all we can do is update plain data in tables. Relational is great for applications that are just updating dumb data and not doing much more. i.e. storing addresses and names is great.

Some would argue that relational doesn't need to deal with the coding or application side effects, relational only deals with dumb data in tables. But OOP is a competitor, and OOP deals with both code and data, in a special way. In OOP the methods launch important code that is integrated with the data of the object. With relational databases the code isn't integrated with the data, it's just a data storage system without OOP methods. How do you launch METHODS, like in OOP? You can't? Or you can, but it's a mess?

Another way of thinking about it: TUPLES or RECORDS in a database don't have any METHODS, whereas objects have methods. That's why people use OOP, because it has methods, also known as procedures.

The closest thing to "methods" in a database are triggers and stored procedures, but it's not really the same, and it is not addressing all the problems. Otherwise people would simply use stored procedures instead of OOP methods, and OOP would be obsolete because you could do everything in relational that you can do in OOP.

This page will probably be hard to grok, because it's a difficult issue to explain. What you need to think about is replacing OOP entirely, with a database and a database language. The only way to replace OOP is to give a database "methods", since methods are what objects have. Some would argue that the goal of relational is not to replace OOP. Well actually the goal is to replace or merge OOP indeed, otherwise we wouldn't create O/R mappers (ObjectRelationalMapper).

The equivalent of an "object method" in a relational database would be a callback or side effect code that is launched when something happens in the database, such as a cell in a column being updated. Do tuples have methods? not really, they are just dumb data. Can they have methods if we wanted? Kind of, that's what this page is about, but it is a tricky topic because it could be violating relational, and/or is unexplored dangerous ground.

Maybe someone has already written about it. Well there is this page, as mentioned: http://www.mountainman.com.au/software/history/relational_model_incomplete.htm

Two solutions to this:

1. A relational language, like TutorialDee. TutorialDee is intended to be an application development language with database features and a database language with application development features. Division into client and server isn't a development issue, but a deployment issue -- ideally under the control of an automated optimiser that determines what code runs where.

2. PostgreSQL (and no doubt other DBMSs, too) provides a NOTIFY facility precisely for the purpose of implementing callbacks.

CategoryRelationalDatabase