4 ms·

We are using azure documentdb for a project at work and it already has like 3-4 structural versions of the documents in the db that has to be accounted for by t

• StavrosK 8y ago
  That's been my experience too. Very rarely is your data model non-relational and schemaless, and if it isn't, you end up having to manage all the relations and cascades and everything yourself, which ends up being a huge pain.
  • e12e 8y ago
    > Very rarely is your data model non-relational and schemaless This of course completely false - which is why we use filesytems and files, more than we use databases ;-) But what I think is less clear and obvious - is when is a document database better than files and the file system? This is kind of the question, are maildirs/mbox any good at storing mail - and are they any good at searching mail? And is sql better at either? This isn't clear cut - there are things like dbmail[d] that just uses postgres and layer imap on top/in front - while a lot of servers prefer some form of file storage augmented with custom indexing. [d] http://dbmail.org/ http://dbmail.org/
    • StavrosK 8y ago
      > This of course completely false - which is why we use filesytems and files, more than we use databases Filesystems and files are good at a lot of things, but not really great at anything. They're a general-purpose abstraction, but the relational model is much more specific.
      • e12e 8y ago
        Of course. I agree with the points made here and in sibling threads about schemas and sql databases. But I also think it's hard to dispute the fact that most data lives in files and file systems. And I think developers too often compare various no(t only)sql solutions with rdms' - without really considering "file-based sql" (sqlite) - or simply file system/DAV based storage (webdav, s3 and work-a-likes, local files, nfs etc). And again - I think it can be easy to see some examples where files are great (store the images for an image gallery), or where relational model is great (transaction data). But I think it can be much harder to see where file storage, or file storage augmented with some form of index - is beaten by a nosql dbms.
    • msbarnett 8y ago
      > This of course completely false - which is why we use filesytems and files, more than we use databases ;-) But consider: there is no application in existence that attempts to work with the contents of every kind of file that can possibly exist on a filesystem. The only kinds of information that any application can reasonably aggregate across all files are those which conform to the standard metadata schema the filesystem applies to all files. Creating an application that aggregated anything else across all files is essentially impossible -- no sane human would attempt to write an application whose functionality depended on them writing parsers for every single file format that could possibly be found in a filesystem. And yet, for most uses of MongoDB it is acting as the datastore for a single application, which in order to do any number of things normally demanded of applications (queries, aggregations, CRUD, etc) must be able to read every variety of document that anyone has ever thrown into the datastore, whether those variations were planned (lets add the following fields to all new Comment documents) or accidental (whoops, a bug led to 3 days worth of Comments missing one or more of the following fields). In the latter scenario, the "it's like a filesystem, store whatever you want!" actively works against the controlling the complexity of the application, to the programmer's great detriment.