There is an online store of goods, it is necessary to implement on mongo. Structure Directory, Subdirectory and Last Level Item. How to make Mongo?

  1. Divide into 3 collections (catalogs, subdirectories and goods)

  2. Or

    catalog : { 1 : { id: 1, name: "Товары для дома", subcatalog: { id: 1 name: "Светильники, products: { 1: { name: "Товар 1", properies: { } } } }, subcatalog: { id: 2 name: "Пылесосы, products: { 1: { name: "Товар 1", properies: { } } } }, }, 2 : { id: 1, name: "Товары для сада", subcatalog: { id: 1 name: "Лопаты, products: { 1: { name: "Товар 1", properies: { } } } }, subcatalog: { id: 2 name: "Совки, products: { 1: { name: "Товар 1", properies: { } } } }, } }

How generally right?

    2 answers 2

    If the task is not educational, then I advise the category of goods not to invest in each other. First, if a search is required, then the structure with subdocuments will make the task very complicated. Secondly, it is not necessary to create such structures taking into account possible changes in the number of nesting levels in the future.

    Simply create ParentId in subdirectories and optionally such caching fields as CategoryLevel , ChildrenCount in parent categories. In the style of the documents it will be convenient to store only the goods themselves and their characteristics, although, for example, the units of measurement in my project had to be carried out in a separate collection.

    For example:

    directories:

     { id: 1, name: "Товары для дома", }, { id: 2, parentId: 1, name: "Светильники }, ...

    products:

     { id: 1, categoryId: 2, name: "Товар 1", properies: { { name: 'Вес', value: 1, div: 'г'}, ... } }, ...
    • and can you give an example using my data as an example - ruslik
    • @ruslik take a look update - FLCL
    • Well, it turns out SQL with relishenami - ruslik
    • one
      @ruslik is ok, it is important to understand the key thing, Monga can store document-like structures and it is also fast compared to the cell-bd, but it is not so different from the latter. For example, trees of dependent objects are a bit different than documents, for such structures there are not even normal ways to make requests, maximum a couple of levels of nesting and they have to be stored as in a regular relational database. - FLCL
    • The only option when you can store a tree of objects is when it is loaded to the client, edited and unloaded back, without any search requests and special operations on it. Something simple, like a notebook with a folder system for storing records. - FLCL

    In nosql, do not think in terms of the 3rd normal form of SQL. In nosql it should be convenient to select all kinds of data that may be required. Obvious requests are to get the goods in a group and a subgroup, to filter the goods by one or several criteria in a group / subgroup. There is no need to store the description of objects in a complex structure that looks beautiful, but which is inconvenient to work with. For example, such a structure is more than enough for the situation described in the question.

    Products:

     {id: 1, name: "Товар 1", categories: [1,45], color: "красный", weight: "120"}, {id: 2, name: "Товар 2", categories: [2,72], size: "45", material:"кожа"},

    ...

    Categories:

     {id: 1, name: "Стройматериалы"}, {id: 2, name: "Одежда"}, {id: 45, name: "Разноцветные тяжести", parents:[1], props:["color","weight"]}, {id: 72, name: "Одежда с размерами", parents:[2], props:["size","material"]}

    In the future, you will expand the structure, but adhere to the principle of making everything as simple as possible. Do not be afraid of duplication of data, and that the database will grow because of this, there is nothing terrible in this.

    • Only I don’t agree with properties, you can stuff them into properties :) and preferably {'color': 'value'} so you can break it down with unwind and then collect everything for the filter + filter will also be easier - Orange_shadow
    • @Orange_shadow is just in that and sense that it was not necessary to collect anything. The document itself is a single whole, as it is inside it that is not stored in principle. That's when it is necessary to work with the collection, the extra aggregation and other maping benefits bring little. in addition to speed issues, there are also questions of the fundamental possibility of sampling. On Habré there were several articles that were filled up first with sql, then nosql, then again returned to sql ... - Yura Ivanov
    • Well, how will you bypass the properties? if you have everything? assemble and disassemble is not so difficult and resource-consuming, though up to a certain point :) - Orange_shadow
    • I do not see a case when the controller (or I twist right away) does not know which document (type of document) it processes, and does not know what properties are in this document, and more importantly, what they mean (what type they have at least and what widget for value mappings will be needed), the enumeration of properties is in the category, if so necessary. If this is a list of documents, then the properties that the list wants to display are displayed, undefined-> empty; if the document is a document card, then in any case there will be a description of the properties (with types and possible values), and a category, etc. - Yura Ivanov
    • And in this case properties:[{"цвет":"красный"},{"вес":"стопицот тонн"}] will not help, will add only dereferencing cycles or properties:{"цвет":"красный","вес":"стопицот тонн"} will be no different from a flat document. - Yura Ivanov