Object relational mappings are over-rated...
1st January 2004
... At least according to Tim Bray:
Lots of architects have learned, painfully, that you usually can’t magick relational rows away behind object/class abstractions. The right way to think about a database is as a set of normalized tables that are designed to be addressed with SQL strings.
This brings in to focus something I’ve been thinking about for quite a while. I always try to abstract away the details of the data storage layer behind some kind of interface, so that none of my front end code ever has to make a direct database call, instead calling methods on my application objects with names like “get_user_by_id” or “get_blog_entries_for_date”. The idea is that I could, if I wanted to, completely switch out the underlying data source. I should also be able to write new front-end functionality that calls the existing application layer methods without having to change anything in the data access code.
There are a couple of problems here. Firstly, I’ve already got a data abstraction layer in the form of SQL. Although there are many discrepancies between implementations, basic SQL statements such as selects and joins should work on pretty much any database. Additionally, in my three years of building web applications I can’t think of a single time I’ve needed to change the data layer for an existing application.
Modern database features such as stored procedures and constraints allow you to move huge chunks of application logic that relates to data coherency in to the database itself. In fact, PostgreSQL even allows you to write stored procedures in third party languages such as Python or Perl. With carefully written stored procedures, much of the important application logic could live in the database along with the data itself—a concept comparable to object oriented programming where the data and the methods that can be run on the data are encapsulated together.
I certainly haven’t made up my mind one way or the other, and at the end of the day the best approach is the one that gets a project completed in a reasonable time frame and that results in easily maintainable code. Plenty of food for thought, in any case.
More recent articles
- llamafile is the new best way to run a LLM on your own computer - 29th November 2023
- Prompt injection explained, November 2023 edition - 27th November 2023
- I'm on the Newsroom Robots podcast, with thoughts on the OpenAI board - 25th November 2023
- Weeknotes: DevDay, GitHub Universe, OpenAI chaos - 22nd November 2023
- Deciphering clues in a news article to understand how it was reported - 22nd November 2023
- Exploring GPTs: ChatGPT in a trench coat? - 15th November 2023
- Financial sustainability for open source projects at GitHub Universe - 10th November 2023
- ospeak: a CLI tool for speaking text in the terminal via OpenAI - 7th November 2023
- DALL-E 3, GPT4All, PMTiles, sqlite-migrate, datasette-edit-schema - 30th October 2023
- Now add a walrus: Prompt engineering in DALL-E 3 - 26th October 2023