AjaxWorld session: Eric Farrar
It’s 11pm: do you know where your queries are?
RIA platforms often wrap underlying database in some abstractions. Object-relational mapping. Hide database complexity.
Inherent difficulties: database normalization is a different pattern than the way we build object collections. DB’s only store scalars. [one other - missed it].
ActiveRecord pattern: the meat of an ORM that handles CRUD operations. Treat regular objects as persistent objects. Ideally abstracts all database interaction.
Trade-offs (no right answers). Advantages include: easy to learn, simplicity, database agnostic. Disadvantages: performance (can be 50% slower); lowest common denominator; concurrency support is harder. Rest of talk is about how to ameliorate some of these issues.
Managing indexes. Ensure an index is present on anything you will search for. Avoid table scans. Performance problem may not appear in development, since table scans are tractable in small db’s. Can’t just index everything: takes space, slows down updates.
Lazy loading: often don’t need all of the data. Danger in getting a whole
object at a time: might pull in more than required. Must be possible to
selectively (lazily) load: e.g. in Ruby ACtiveRecord :select => ["name"].
Client-side joins: can issue lots of individual queries rather than one join
query on the server. In Ruby ActiveRecord :include => [:office]. Eager
loading pattern.
Summary: be aware of what the underlying database is doing with your ORM models. Which seems plausible enough, though I’m not quite sure why this talk was at an RIA conference. I was hoping to hear some comments on the difficulties of managing queries when the app code is running on the client side in potentially a much restricted computational environment (and also outside the firewall).