PGCon2011 - Add 4 Video (2015.09.18)
PGCon 2011
The PostgreSQL Conference
| Speakers | |
|---|---|
|
Christophe Pettus |
| Schedule | |
|---|---|
| Day | Tutorials - 2 - 2011-05-18 |
| Room | DMS 1120 |
| Start time | 09:00 |
| Duration | 03:00 |
| Info | |
| ID | 340 |
| Event type | Workshop |
| Track | DBA |
| Language used for presentation | English |
Life with Object-Relational Mappers
Or, how I stopped worrying and learned to love the ORM
Object-Relational Mappers (ORMs) are the primary interface that application programmers now use to interact with SQL databases. Any DBA can list the problems that they create, but how can we move on to solutions that don't involve a complete reengineering the ORM-database interaction paradigm? Rather than simply declaim that ORMs are bad, let's find a way of mitigating the problems that existing ORMs create.
The database community seems to have been blindsided by the rise of Object-Relational Mappers (ORMs) as the primary database interface technology, even though ORMs themselves have been around for years (the core concepts date to the early 1990s and before). The problems with ORMs are real: Poor-quality SQL, schemas that are not well-matched to the capabilities of the database, and database access patterns that are hugely inefficient.
Yet ORMs are here to stay, and we must deal with ORMs that currently exist, rather than the theoretical ORMs we wish we had. As database architects and engineers, ORMs are now part of our client universe, and we need to understand them and find ways of working with, rather than against them.
We'll talk about why ORMs have the characteristics that they do, and why they appeal so strongly to application programmers over direct-SQL model. Using real-life ORMs, we'll explore ways that database architects can guide the development of ORM-based applications in a way that mitigate the problems that an ORM can create in database interaction. These include ORM-friendly changes to the application, ORM-invisible changes to the database, and (when required) spot alternations to the application to avoid disasters.