I have an issue with structuring som data. The idea is to have some sort of menu card, where you can build your own menu. The different products are categorized into groups, and in some of the groups you can choose between eg. three different predefined 'submenus' - so you would have nested menus. As it is now, they are simply stored as nested trees in the database. The problem is, that we have a lot of different views, where the this structure is somehow irrelevant (eg. (complicated) list views with chosen products). This is pretty impractical to iterate over all these substructures and make them into a list, and it feels wrong to store the data in this way, just to make the view.

My suggestion is to simply have the products in a list, with an attribute indicating which menu they belong to. My problem is, that I don't know any smart way to store the structure of the menus belong to the attribute, and still making it possible to reconstruct the menu as it looked when they created it (ie. with all the submenus they did not choose) - even though the template menu has changed. Please note that that the structure cannot be hardcoded in any way, since the template is dynamically constructed by "menu designers".


A potential solution, create a parent child relationship in the table.

Table Constructed Menu, The Menu Id is the original Menu item if there is a list of pre-defined menu items.

  • Id, ParentId, Name, Menu Id
  • 1, Null, Root Menu, 9
  • 2, 1, Sub Menu 1, 15
  • 3, 1, Sub Menu 2, 25
  • 4, 3, Menu Item under Sub Menu 2, 45

..And So forth. Most databases support a nested type of query. For example, SQL Server uses common table expressions (CTE).

Then you can build any type of menu structure from a list of standard menu items.

  • Thanks for your reply. But then I would still have no connection to which option was selected on the main menu - and if I change the mainmenu the children would be changed too. – Anders Oct 6 '17 at 20:45
  • True, if you removed a parent all the kids could potentially be removed since the relationship is hierarchical. – Jon Raynor Oct 9 '17 at 14:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.