Home Original page

Table Oriented Programming

Michael Hobbs michael at hobbshouse.org
Thu Feb 12 14:10:15 EST 2004 
Yeah, yeah, another X-Oriented paradigm, but please hear me out.

I have recently been studying up on EJB's in order to extend my resume.
I have looked at J2EE several times over the past years, but have never
been impressed by it. Now that I've studied it in detail, I know why. A
strongly typed language such as Java is poorly suited to model tables
and relations. 

I got to thinking that a more dynamically typed language, such as
Python, would be a more natural fit. I've always been fond of the
table-oriented programming ideas described in
http://www.geocities.com/tablizer/top.htm, so I'm thinking that if
Python could be extended to handle table-oriented programming as
seamlessly as it handles object-oriented programming, it could become a
really valuable language for writing enterprise components, a la EJB.

Does anyone know if anyone has already walked this path?

I've given it a little thought myself, and here are some of my
[incomplete] ideas:

- Tables would be first-class values, just as classes are.
- A table may be stored completely in memory, or it may represent a
table stored in a database engine.
- A table may represent the result of a query.
- Queries are performed using a sequence of operators, rather than
relying on SQL.

Consider this example code:
  departments = DepartmentTable
  employees = EmployeeTable
  johnsDepartment = (departments * employees) / 
    (employees.dept == departments.dept) /
    (employees.name == 'John') %
    departments.name
  print johnsDepartment[0].name

In the code above, the "*" operator performs a cartesian product, the
"/" operator performs a selection, and the "%" operator performs a
projection. If the DepartmentTable and the EmployeeTable are stored in a
database engine, the expression above would generate a SQL query similar
to "select department.name from (select * from department, employee
where employee.dept = department.dept) where employee.name = 'John'". If
the expression had been written "(departments * employees) /
(employees.dept == departments.dept and employees.name == 'John') %
departments.name", the resulting SQL would be similar to "select
department.name from department, employee where employee.dept =
department.dept and employee.name = 'John'", that is, without the nested
SELECT.

Of course, the entire code above could be reduced to a single line:
  print ((DepartmentTable * EmployeeTable) / (EmployeeTable.dept ==
DepartmentTable.dept and EmployeeTable.name == 'John') %
DepartmentTable.name)[0].name

Perhaps the list-comprehension syntax may be better suited than
arithmetic operators. Like I said, my ideas are still a little
incomplete.

Please forgive me if this has already been discussed to death,
- Michael Hobbs
More information about the Python-list mailing list