One of the many project I am working on at the same time is content based. Different sources of content have different plugins that get the content and then store them with the relationships they have with other data. It is easy to design a base 'Content' class. Where there is an Image, Text, Video ect as subtypes of that. Then based on the source there is another subclass with specific infromation. In RDBMS this is a mess, with many different classes and each time I need special information things get ugly because I have 2 choices. Either grow a table or stuff some things in a generic field. When developing a prototype this really is a bummer I have to do a lot of thinking about data storage that I really don't want to.
Document is cool
What this boils down to in Documents is a content type (Image, Text, Video ect) and then source. Any addional information needed to be stored associated with the specifics just lives in the document. The only tricky part is populating from a view (query). I need to decide based on the type and source which class this is for and bam I am done. So much simpler.
Graph + RDBMS = Pain
Another thing this project does is create links between content, collection of content and collections of collections. Somewhere in there is a graph of content. Trying to traverse a graph with SQL without way to many queries is just hurting my head. From what I have heard writing a bunch of stored procedures code can reduce the volume of SQL however I think the point is unless you have to. Luckily I found CouchDB to try this with. I have not started to implement it but it fits in my head how I can easily traverse the graph with CouchDB.
Now to the belly of the beast to see if my theory holds any water.
0 comments:
Post a Comment