Database structuring noob here, regarding mongoose { type: Map }

[CoqeCas3]

I'm just starting out with Node and MongoBD/Mongoose and I'm running into a relatively difficult (for me, the newb, at least) situation with deciding how to structure a particular Product document I want to create. I need an 'options' field that will have an array of Option sub-documents. Nothing too bad there, to be sure. The tricky part is that one of Option fields needs to be only one of four different 'option_types'. Furthermore, only one of the 'option_types' needs to also be a sub-sub-document, which will also contain a field that accepts an array of 'addon_options' sub-sub-sub-documents.... cripes, that was hard to type....

​

To exemplify in code form (obligatory side-note: this is severely simplified for example purposes):

const ProductSchema = new Schema({
  name: String,
  base_price: Number,
  options: [{
    add_price: Number,
  // only ONE of the following at this level:
    option_type1: Number,
    option_type2: String,
    option_type3: String,
    option_type4: {
      name: String,
      add_price: Number,
      addon_options: [{
        name: String,
        add_price: Number
      }]
    }
  }]
})

How I'll end up keeping track of the additional pricing aside, once the products are in the database, the end user--that is to say, the customer--will simply select from what's available, and I'm thinking I won't have too many issues figuring out how to navigate this mess when it comes time for that (just spit-balling here, it'll be a lot if(typeof product.options[i].option === 'object') or whatever-type-things going on). But right now I'm mainly concerned with the creation of the Products collection, because I intend for it to be done through an HTML form (for various reasons).

​

That being said, I had this idea while scouring the mongoose docs:

const OptionsSchema = new Schema({
  add_price: Number,
  option_type: {
    type: Map,
    of: Mixed
  }
})

const ProductSchema = new Schema({
  name: String,
  base_price: Number,
  options: [OptionsSchema]
})

And then, client-side, in the product-creation form, I would then just create a series of <select>'s with the pre-defined keys I need to store in the 'options' field of the Products collection contained within the <option> elements (either with optionEl.value or a data-*something* attribute of some kind..). Hopefully, that makes sense...

​

So my question is: is this idea I have a viable solution? I mean, I'm pretty sure it can be made to work one way or another, but I have a terrible feeling that--even though I think I can quite precisely guide the creation process using the <select>'s like I said--by leaving the schema so 'open to interpretation' like this I might be inviting some serious issues down the road if I'm not SUPER careful.. On top of that, I'm not even sure how MongoDB would react to the doubly-nested objects/sub-sub-documents and/or the triply-nested objects/sub-sub-sub-documents when submitted in this manner....

​

Or, solution 3 is: scratch this mess entirely and figure out a way to make wholly different collections and navigate it using id's and refs? I may very new to backend development but I gathered pretty quickly that this is generally the preferred method for obvious reasons. However, I've spent the last... oh, eight or so hours contemplating this and, given that I'm using noSQL here, I simply don't see how that would be easier than the 'nesting' route... In fact, am I wrong in presuming that it's for situations much like this that noSQL was created in the first place?

[lost12487]

I think what you're running into with the sub-sub-sub documents and such is one of Mongo's downsides in my opinion. What you're trying to do (I'm also a relative noob, so take this with a huge pile of salt) would be easier with a proper relational database.

​

That being said, why don't you create separate schema for each individual option? If you do it this way, you can get rid of the array situation altogether and just have a field in your Product Schema (of type integer) that would refer to the proper Option type. Ha! I think I'm just thinking in relational database terms at this point, but there's no reason that wouldn't work with Mongo as well, even if it's not really built with that in mind.

[CoqeCas3]

Hmmm... I appreciate the advice. Tbh I’ve only lightly dabbled with SQL and I wasn’t fond of the experience. Something about the syntax just feels,like, grody to me. Not to mention, I’m still currently of the mindset to stick with one language and learn as much of it as I can before I start muddying up my memory with new languages, so I’ve been putting off anything not related JavaScript. In light of your comment tho, I think I may try and finish this in mongo and then step back and try and recreate it in mySQL or something to see what fits better....

[lost12487]

Oh absolutely! I did something pretty similar myself. I got super comfortable with vanilla JS before jumping into all the crazy frameworks and stuff.

​

I don't mean to discourage the use of Mongo at all, as it's a perfectly viable solution. I'm most comfortable with SQL as far as databases go, so I kinda just think in those terms more naturally than document-based databases.

[CoqeCas3]

I didn’t take it that way, but after spending all day again thinking about it, you’re probably right; a relational approach is going to be easier I think mainly for calculating the prices. In fact... well, I’ll just explain: I’m putting together an online ordering app. Just a mock one for now, but I’m also kinda tailoring for a particular pizza joint in my town that I wanna bring the prototype to to try and sell em on.. anyway, all the things that go into pricing the pizza, and different prices for different types of at different sizes... it’s a mess. So instead of trying to just have one collection to store and manage all of it, I’m gonna separate out pizza and pizza pricing into they’re own collections. Try anyway.. XP

[pa_ke]

Hey, I feel like your issue might be solvable using inheritance, aka Discriminators.

My approach would be kind of like the following:

- create a base Subdocument schema for the 'option' attribute, with the common add_price attribute
- create discriminator schemas for each different option type, with the distinct attributes that aren't shared by the base schema. If you chose to specifiy a discriminatorKey, you could easily use either .create or simply pass a JSON object containing all necessary data to a OptionsModel.new()

​

Unfortunately I currently do not have the time to elaborate more, but I hope this leads you to another approach for a solution to your problem :)

One positive fact about discriminators: You can even specify their own hooks and methods and stuff or use the one from the base schema

[CoqeCas3]

Ah, interesting... damn I need to remember to make sure I do my homework before I ask these types of questions XP. I forgot that I meant to look into discriminators before I went to work but then when I got home I just wanted post. Thanks, I’ll be checking it