> > 1) When should CastedModel be used instead of ExtendedDocument? In > some of the examples I see you are saving a CastedModel as a field > inside a document. Other times you are saving an ExtendedDocument > inside a document. But it appears to me that the end result is the > same in the database. Can (or should) a CastedModel also be saved as a > top level document, and if not, why not just use ExtendedDocument for > everything to allow that flexibility? >
ExtendedDocuments == real DB documents CastedModel == Hash inside a document A Casted Model doesn't have a save method or a create method, it also doesn't have an id, revision. You can access the parent of a CastedModel if you want to save it. You might want to cast an ExtendedDocument in the off chance that you have a model that's being stored as a document as a well as an attribute, I would recommend against doing that as you might encounter some weird behaviors. 2) Collections... When implementing something like tags for instance, > do you think it's better design to add each new tag to the document as > a separate property field, or as a cast_as collection? (BTW, tags may > be a bad example because they could simply be strings, but assuming I > want them to be typed.) > I usually use cast_as collections. But I usually cast to CastedModels, not ExtendedDocuments. 3) Sticking with the tag example above, if I am also creating top > level documents for each tag in my database, do you think it's good > practice to stay denormalized by also storing the whole tag in the > tagged document? So... > In the case of tags, I would strongly suggest to store them as an array of strings and use views to get the data you want. You can for instance create a view that will emit each tag for a document as well as 1. This way you can easily create a cloud map using a reduce function. (I believe you will find some examples on the wiki). I totally don't see the need to store tags as their own documents. In real life, what would you do? Write down a sheet per tag and then add post-its with the ids of sheet for each of your items? Probably not ;) 4) And finally, what are your thoughts on using the _attachment field > for storing something like profile photos... or is it still better to > use a solution like Paperclip + AWS? It all seems very nice from > Futon, but do document based databases really make this the better way > to go. What about CDNs? > Be careful with attachments, you can deal with it using 2 different ways. Inline your attachments in the document (bad idea), or make an extra call to save the attachment like an email attachment. I personally find it very interesting and attractive. One small issue I'm working on is how to stream attachment if your db isn't available from the web. Regarding CDNs, well.. the good news is that you can now create your own really easily, by setting up a server in asia and one in europe and replicate your dbs ;) Not having to deal with Paperclip/attachment_fu and s3 is just awesome. (note that you could use ec2 instances just to serve assets.) - Matt On Thu, May 21, 2009 at 3:39 PM, Peter <[email protected]> wrote: > > Matt, > > Thanks again for sharing these examples. After looking them over (and > reading the specs) I have a few new questions. I hope others may find > this useful as well: > > > 1) When should CastedModel be used instead of ExtendedDocument? In > some of the examples I see you are saving a CastedModel as a field > inside a document. Other times you are saving an ExtendedDocument > inside a document. But it appears to me that the end result is the > same in the database. Can (or should) a CastedModel also be saved as a > top level document, and if not, why not just use ExtendedDocument for > everything to allow that flexibility? > > > 2) Collections... When implementing something like tags for instance, > do you think it's better design to add each new tag to the document as > a separate property field, or as a cast_as collection? (BTW, tags may > be a bad example because they could simply be strings, but assuming I > want them to be typed.) > > property :tags, :cast_as => ["Tag"] > > vs. > > tag_one: { > "name": "wild", > "couchrest-type": "Tag" > } > tag_two: { > "name": "mild", > "couchrest-type": "Tag" > } > > > > 3) Sticking with the tag example above, if I am also creating top > level documents for each tag in my database, do you think it's good > practice to stay denormalized by also storing the whole tag in the > tagged document? So... > > # normalized > property :tags, :cast_as => ["String"] # An array of Tag ids > > vs. > > # denormalized (assuming this stores the whole tag) > property :tags, :cast_as => ["Tag"] > > Or even... > > # normalized > tag_one_id: "0ec292a425aa3225994832a086c95d7a" > tag_two_id: "e76bb7825fca3f678b69d88c2a831edc" > > vs. > > # denormalized > tag_one: { > "name": "wild", > "_rev": "1-3363921651", > "_id": "0ec292a425aa3225994832a086c95d7a", > "couchrest-type": "Tag" > } > tag_two: { > "name": "mild", > "_rev": "1-1029362251", > "_id": "e76bb7825fca3f678b69d88c2a831edc", > "couchrest-type": "Tag" > } > > > > 4) And finally, what are your thoughts on using the _attachment field > for storing something like profile photos... or is it still better to > use a solution like Paperclip + AWS? It all seems very nice from > Futon, but do document based databases really make this the better way > to go. What about CDNs? > > > Thanks again, > Peter > > > > On May 15, 1:02 am, Matt Aimonetti <[email protected]> wrote: > > After so many people got excited about CouchDB, I put quick example > > together: > > > > http://gist.github.com/112109 > > > > I'll try to write a blog post in the next few days. > > > > - Matt > > > --~--~---------~--~----~------------~-------~--~----~ SD Ruby mailing list [email protected] http://groups.google.com/group/sdruby -~----------~----~----~----~------~----~------~--~---
