that is just a proposition, i know that if you need a non relation db the best thing to do is to have a non relational data store.
but you need a relational data store only if you need to query non relational data, in the other cases you can use a relational db, because relational db got foreign keys, a things that rocks! i need to handle documents (real documents, paper), and what i have done is to store cleaned_data inside a model and give to that a number. i need to do a lot of different documents (iso 9000 sheet, ddt, invoices, quotations), and i don't need to query non relational data that are inside (not all of them, of course). what i need, instead, is to have some common field for all my document (document date, document number, document prefix, document owner, and maybe a content type field) to query and order them, and store them in an unique db table. that kind of schema is better than a non relational database, because i can use foreign keys and index for fast query the things i need to query, and create different kind of classes to handle different kind of documents. to archive that kind of job, a json field is great. and i dont't whink i'm the only django user that needs stuff like that (business staff). sometimes you might need to save raw html inside db, and sometimes you may need to store raw json to db. that's all. On 8 Nov, 19:47, diogobaeder <diogobae...@gmail.com> wrote: > Hi, guys, > > I agree that we should use the right tool for the job; But even a > relational database can be used for semi-structured data when it's not > going to be directly queried. Matter of fact, there's even a design > pattern recognized for > that:http://martinfowler.com/eaaCatalog/serializedLOB.html > > Example of use: think of a semi-structured data store (in a relational > database) that is going to be read through a search engine (think > about ElasticSearch of Solr, here). > > But yes, if you're going to need to query for this data by parts of > the JSON field, then you're shooting your own foot. So, in the end, we > have to think a lot about what's the problem we're trying to solve - > it's not as simple as "don't use RDBMS for non-relational data" -, > IMHO. > > Well, at least here's my 2 cents. > > Cheers, > > Diogo > > On 8 nov, 08:34, Tom Evans <tevans...@googlemail.com> wrote: > > > > > > > > > On Mon, Nov 7, 2011 at 11:48 PM, Torsten Bronger > > > <bron...@physik.rwth-aachen.de> wrote: > > > > While I appreciate that Django core is supposed to enforce good > > > design practices, one must be careful with that if some practice may > > > have valid use cases. You cannot prevent the user from shooting in > > > the foot anyway. > > > > While we make extensive use of the relational model in our project, > > > I remembered to have a couple of JSON fields (though we don't have a > > > field class them them so far), so I skimmed through our code to see > > > why we did this. > > > And so do I - the main point here is that we have both successfully > > loaded the gun and aimed it at our foot without this field existing in > > core. I think it's important to have that distinction between things > > you can do and things you should do, in order to make you think > > "should I really be doing this". > > > Cheers > > > Tom -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
