On 16/03/10 6:06 PM, Nathan de Vries wrote:
On 16/03/2010, at 4:37 PM, Xavier Shay wrote:
If you must store them in the DB, perhaps consider a separate table for
unconfirmed entries. It's conceptually clearer and a much nicer way of DRYing
thing up.
Creating a *duplicate* table for storing unconfirmed records is DRY? See,
madness!
heck, have 5 tables with the same schema. Modules + other basic meta
programming mean you hardly write an extra line of code, and you don't
compromise your DB design.
We have one app that from a single ~30 line hash generates migrations,
models, blueprints for testing, and code to get seed data into those
tables. If you understand those 30 lines, you understand a large part of
the app.
Say you're building a cart checkout process and you'd like a shipping& payment details
confirmation screen ("Please verify that the following shipping& payment details are
correct"). Would you create a separate record for the order during confirmation, and then
move the order between unconfirmed/confirmed tables once the user finalises the checkout?
sure, why not? It's easier for my brain - don't need to remember to
scope anything, harder to screw things up (like shipping an unconfirmed
order, or presenting a report to the boss containing unconfirmed
orders), and the code/flow of data is easier to follow. The only "extra"
bit is moving rows between tables - which you solve once and you're done.
Further, the data has very different profiles - unconfirmed orders are
pretty much transient/throw away, where as a confirmed order needs to
stick around.
This becomes *especially* relevant when you start getting more than one
'confirmed_at' type column on your tables.
small, elegant, focused tables. The same way we design models.
Rule of thumb - if a column very rarely needs to be NULLable.
Xav
--
You received this message because you are subscribed to the Google Groups "Ruby or
Rails Oceania" group.
To post to this group, send email to rails-ocea...@googlegroups.com.
To unsubscribe from this group, send email to
rails-oceania+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rails-oceania?hl=en.
