Discussion (4)2
Log in or sign up to continue

The idea of document DBs is as follows. You always have constraints on data: what fields are there, what datatypes are there and so on. In the case of a relational DB the constraints are checked and enforced on a database side - you define a required timestamp field once and when you request the data back, hundred times out of a hundred, you get back a valid timestamp field.

On the one hand this is good - separation of concerns and all that, on the other hand what if your application data requirements change often? Or what if you need to store data for several versions of your application at once? In that case maintaining a constraints on a db side becomes cumbersome.

Document databases are created to work in this type of situations. On a DBMS side you now only enforce the existence of collection, id key and maybe some required properties if you're 100% sure they are always available. Everything else is optional and entirely the concern of the application. Document, after all can have any number of fields or don't have them at all. And it is application job to make sense of it.

In your case the schema is extremely stable - the standard defining RSS was aproven in 2005 and, frankly, not likely to change, ever. It is as one may say feature complete.

Using XSD schema you can easily generate the classes  in InterSystems IRIS and import your RSS data into them.