This morning's talk is with Thomas Gagne, who is the technical lead for InStream Services. Thomas is going to talk about how they use databases, and how they map objects into them. Thomas has an interesting take on this field: his assertion is that there is no Object/Relational impedance mismatch. You can read Thomas' take at his blog.

Big Statemements

• The database is the biggest object in the system
• The database is the most important object in the system - everything else is cosmetic
• The database is not invisible

The database is a Semantic Persistence Store (SPS) - a self contained component for managing data. Other examples of an SPS: X.500 Directory Services, Domain Name Service (DNS).

Another concept: Message Oriented:

• Communicate between two loosely components
• Characterized as the message having its own identity
• Its own Object
• Believed by Alan Kay to be very important

So what is the O/R impedance mismatch? The attempt to map tables and columns to objects and methods. At the bottom, OO and RDB are similar but fundamentally different. In Thomas' shot, there is no separation between the OO and Relational people - the same staff handle the applications and the database.

So why are we here? Assertion: The impedance mismatch does not exist in OLTP systems. OLTP is loosely coupled and highly cohesive. Observations:

• Business came before the technology
• The technology is there to assist people

Smalltalk Rules:

• Private Data
• Activation via message sending (late binding being important)

How is an SPS like a Smalltalk Object? It's a subclass of a more general database. It can dehydrate and rehydrate. It's a state object, it's a singleton. The database is reflective (you can ask the database questions about its structure). Reacts poorly to tight coupling - changes to internal data can be hidden behind an API.

How do they differ? A database does not enforce API only access (variables are public by default). So now Thomas is off to an example - a simple banking application with four methods: login, logout, add money, remove money. The idea is that by giving the database an API (stored procedures in this case), you isolate it from changes at the application level. They don't have application level SQL at all - they have "guarded" the database with a stored procedure API.

Technorati Tags: smalltalk, relational