[std.database]

[Jacob Carlborg]

On 2011-10-12 09:05, Jonathan M Davis wrote:
> On Wednesday, October 12, 2011 08:57:54 Jacob Carlborg wrote:
>> On 2011-10-11 23:31, Andrei Alexandrescu wrote:
>>> On 10/11/11 3:05 PM, Jacob Carlborg wrote:
>>>> If we're talking use cases and high level interfaces I would go with
>>>
>>>> something like:
>>> [snip]
>>>
>>>> I recommend that everyone take a good look at ActiveRecord in Ruby on
>>>> Rails:
>>>>
>>>> http://guides.rubyonrails.org/active_record_querying.html
>>>> http://guides.rubyonrails.org/association_basics.html
>>>> http://guides.rubyonrails.org/active_record_validations_callbacks.html
>>>
>>> I confess the example you gave looks very foreign to me. From consulting
>>> http://guides.rubyonrails.org/active_record_querying.html, I see Ruby's
>>> active records esentially recode relational algebra in Ruby (as for the
>>> constructs the equivalent SQL is shown).
>>
>> Yes, exactly. The point is to have as much as possible in functions
>> instead of string literals and have a more Ruby like API than an SQL
>> looking API.
>>
>> connection.select("*").from("users");
>>
>> instead of
>>
>> connection.execute("select * from users")
>
> I don't know what all of the pros and cons are, since I'm not all that
> experienced with DB stuff, but on the surface at least, from the perspective of
> usability, I don't see anything better about the first one than the second one.
>
> - Jonathan M Davis

I usually prefer calling methods and functions instead of writing 
everything in a string literal.

These forms might not make a big difference but when you use an object 
oriented API I think it does.

Take this Ruby example:

Post.joins(:comments => :guest)

Produces the following SQL:

SELECT posts.* FROM posts
   INNER JOIN comments ON comments.post_id = posts.id
   INNER JOIN guests ON guests.comment_id = comments.id

-- 
/Jacob Carlborg