2

At first, I thought it was pretty cool that you can add something to an object without it being defined in the model. But now I can't imagine how this is used in a web application like a Ruby on Rails application. What use cases require dynamic fields and how does the UI allow a user to define these dynamic fields? Do you let the user set the key for the dynamic field (with a text box or something)? Do any of you know off the top of your head any demos are applications in general that showcase the real usefulness of dynamic fields? Also, if you plan on reading these dynamic fields, wouldn't you need read_attribute (in the case of RoR) with the name of the "dynamic" field already planned for ahead of time?

I'm asking this question because I have an assignment in school to wrap an application around PostgreSQL and a NoSQL database (I chose MongoDB). I have successfully done this, however, every attribute that I add to any objects that I have defined on the MongoDB side is already defined in the model. I want to show that I'm aware of this capability, but I can't come up with any reason to use dynamic fields and I can't find results on the search, "purpose of dynamic fields in mongodb" or "dynamic fields mongodb demo".

Thanks!

Jake Smith
  • 2,332
  • 1
  • 30
  • 68
  • What's a dynamic field? MongoDB is schema-less, so you can add fields at any time. In certain applications, with those that have a predefined, it may not make sense to add new fields (again, without adjusting the schema). – WiredPrairie Apr 08 '14 at 00:35
  • I'm trying to wonder why they offer the ability to add fields to a model that does not have that field defined in it. Does that make sense? I know that you can add fields dynamically. I'm wondering about truly dynamic fields that do not appear in the model definition – Jake Smith Apr 08 '14 at 00:58
  • Perhaps an example of a "dynamic field" would help clarify things. – mu is too short Apr 08 '14 at 01:08
  • Well it would because that is essentially my question. I really want to know what the use cases were that convinced the people who developed this type of database to want to give that functionality: the ability to add any field of any type at any given time of any given type. Of course it is more complicated than that when scalability is a concern. I'm just trying to understand this particular aspect of MongoDB. – Jake Smith Apr 08 '14 at 04:39

2 Answers2

2

First of all "Dynamic Field" is a Mongoid concept, and Mongoid is just a ODM to map ruby objects into MongoDB documents. MongoDB doesn't have and doesn't need a concept of Dynamic Fields since it is schemaless. Although this theoretically means that every document in a collection can have a different structure, this is never a practical application for a MongoDB.

An ODM such as Mongoid provides a useful mechanism to define a schema at the application level rather than in the database itself. In this context there are two big benefits to Dynamic Fields.

  1. The ability to add sub documents that have varying structures. For example you can have an Animals collection. Each type of Animal could have different body parts. But in MongoDB I don't need a "tusks" column just because some animals have them.
  2. The ability to change the schema without touching the database. It is very common to add functionality to a database through additional "columns". Using Mongoid/MondoDB this can happen in the application code, as easily as changing an application class -- completely transparently with respect to the database.
mjhm
  • 16,497
  • 10
  • 44
  • 55
  • Thank you, this is really ringing true with what is being discussed in class right now. Thanks for the explanation. I guess my question is really about what an application does or needs to be that requires a MongoDB database storing information in a way that a relational database can't perform. How does the User Interface of an application change when you have a schema-less database? I'm used to an application being, essentially, a collection of forms that requires the same attributes to be specified repeatedly. What type of application begs for MongoDB to be used instead of PostgreSQL? – Jake Smith Apr 08 '14 at 05:09
  • 1
    I think http://docs.mongodb.org/ecosystem/use-cases/ are pretty good examples. In particular I've worked extensively with the "Product Data" use case. In that case the data is very well suited for MongoDB because the data items are complex and highly varied, and the relational requirements of the data items are fairly simple. – mjhm Apr 08 '14 at 05:34
0

I think you took wrong aproach to asking/looking for answer to this question,in my opinion best answer will be from the source and here is a post from MongoDB blog, I hope it will help you out.

http://blog.mongodb.org/post/119945109/why-schemaless

scx
  • 2,749
  • 2
  • 25
  • 39
  • Thank you but I think you misunderstood my question. I do have a fairly good understanding of the benefits and disadvantages of a schema-less database for agile development purposes (avoiding troublesome migrations in a large-scale scenario). My question was really about what the importance of allowing dynamic fields to be added to models that were not previously defined. If you don't know how to refer to something previously, how do you build a view on it in advance? – Jake Smith Apr 08 '14 at 04:35
  • If a user can add anything of any type at any time, how do you prepare for that? My models have fields defined already. But how do I develop my application to allow for fields that users define themselves at run time? What types of use cases would require that? – Jake Smith Apr 08 '14 at 04:35
  • 1
    Yea I have probably not got your question correctly, seems like mjhm already provided you with mongo doc use cases in the comment so that makes everything clear. – scx Apr 08 '14 at 10:47
  • I'm sorry for not being clear. Thank you for your help anyways! – Jake Smith Apr 08 '14 at 21:04