ActiveRecord, by Rabble.
- Rails ActiveRecord is mostly database agnostic.
- Good subset of the SQL standard is supported, so you can migrate very easily (this is what OS X Leopard will do – develop using sqlite on your workstation, then migrate to mysql on the server).
- Integer primary keys, and classname_id foreign keys. Single table inheritance is what really works well.
- What ActiveRecord doesn’t like:
- views
- stored procedures
- FK constraints
- cascading commits
- split/clustered DBs
- enums
- Complexity is best located in the code, not in the database, according to the Rails developers.
- Avoid SQL injection with find. Use an array or let it do the quoting for you. By itself, it allows you to do stupid things – so avoid cross site scripting, etc.
- Joins are very rarely used, you use ActiveRecord relationships.
- Some associations:
- has_one – when the FK is in the OTHER table
- belongs_to – when the FK is in THIS table
- has_many
- has_and_belongs_to_many
- DBAs like FK constraints, but the Rails way is to really just use validations.
- ActiveRecord returns enumarable objects, which look like arrays
- ActiveRecord also allows for output formats – like to_yaml, to_xml, to_json. So your database records can become XML pretty easily.
- find_by_sql – use it when you’re finding ActiveRecord isn’t suitable for you, i.e. you’re doing something that is not very standard.
Rabble also gave us an anecdote from his Odeo days. They thought that grabbing feeds should be done in parallel. Which is when they used RubyThreads. And suddenly, they were getting some horrendous database problems, duplicate records and so on. Moral of the story: RubyThreads and ActiveRecord don’t mix. A member of the audience mentioned that using find_by_sql consumed about 1MB of memory in his application, however, using ActiveRecord to do the same thing was costing about 20MB per thread.
Technorati Tags: ruby, svrc2007, database, sql, mysql, ActiveRecord