Javan Makhmali wrote:
Hello, I'm new to the list, ruby, and San Diego, but I'm enjoying all of
them.
I'm trying to determine the best practice for creating controllers and
views to CRUD various model relationships (currently habtm and checkboxes
for categories). I've found some examples (http://
wiki.rubyonrails.com/rails/pages/CheckboxHABTM), but after reading the
2nd edition of the Agile book, they seem dated. Setting up the models and
migrations to create relationships is very clear to me, but putting them
to use isn't and seems somewhat glossed over in the book. Any tips would
be very appreciated.
You are asking about classical database design; about normalizing the data.
If you read some of the classical books on the topic, they will say things
like "never use a NULL in a table. Instead, create a child table and use a 1
to zero-or-more relation between them." That's not the exact rule, but you
see what I mean.
However, Rails does this one better. Classical database design rules tend to
treat the database as ossified. You are "not allowed" to refactor a
database - especially when you must remain compatible with your customers'
live data!
Rails follows patterns which are probably in the book /Refactoring
Databases/. Each time you upgrade a database, you write a little script that
migrates your live data into the new schema. You release by running all
these scripts in batches. Rails does what no other object-relational adapter
layer does - automate all that AND make it all database-agnostic.
So under Rails, you can follow "emergent design" with your database. Write
the simplest one you can for immediate needs, and upgrade it as your project
grows.
And write lots of unit tests. I had to learn to do that back when almost
nothing supported them. Now Rails supports them, for some of the hardest
situations in programming. Including unit testing and refactoring databases!
--
Phlip
http://www.greencheese.us/ZeekLand <-- NOT a blog!!!
_______________________________________________
Sdruby mailing list
[email protected]
http://lists.sdruby.com/mailman/listinfo/sdruby
