5

I have an application that basically consists of a lot of screen so user needs to navigate a lot (like go from A>B>C>D) etc.
I have been thinking how to implement this (mainly hold the structure of the menu) as it needs to be on-screen menu (custom, no menu strips etc.) and did not find any solution.

Now I realized I could use a database for that, which would allow me also to change strings later with no impact.
My idea would be to have a table for each level (1-5) with options available. Once the user selects an option, the program will select any items in the table (CurrentLevel+1) based on its ID. Seems really a good solution to me but I am not a programmer (rather than an analyst).
Or even I could use specific table names and hold the table name in a specific column, for example:

User selects Settings

Program checks that with Settings, there is a table associated "SETTINGS" and query this table for all items available

Does this make sense?

Improve this question
3
  • If you are not a programmer (i.e. a developer) why should you care? This is a programming question (and it should be answered by the developers)! But defining some behavior thru configurable data is generally a good idea.
    – Basile Starynkevitch
    Jul 27, 2014 at 9:35
  • ACtually I am a part of featured time in AGile env, so I am expected to deliver that ;)
    – John V
    Jul 27, 2014 at 10:32
  • Another factor to keep in mind when choosing where to define this menu is version control. If the menu structure satisfied a business requirement, then it is product source, so you ought to treat it as such. If you keep your database code in source control with your app (usually a good practice), then you're all set.
    – Brandon
    Jul 27, 2014 at 12:32

4 Answers 4

Reset to default
7

Your menu is essentially a tree, so could be stored in a single database table:

ID (number, not null)
PARENT_ID (number, can be null)
DESCRIPTION (text)

where PARENT_ID is null for top-level menu items.

You might need one or more additional columns to hold the behaviour you want to associate with the menu items (e.g. an action ID, command name or URL).

Improve this answer
3
  • You might have forgotten a column which gives the actual behavior (perhaps as a functional value, i.e. a closure) of the menu... Or you want the application to hard-code its behavior from the menu item ids?
    – Basile Starynkevitch
    Jul 27, 2014 at 9:38
  • @BasileStarynkevitch Agreed, but as you point out there are several approaches to that (not all of which need another column), and I expect OP already had an approach in mind for the multi-table version. I'll update my answer to clarify.
    – Matthew Strawbridge
    Jul 27, 2014 at 9:49
  • Bingo. Might want to add an example query though. It's not the most intuitive database structure if you've never dealt with it before.
    – RubberDuck
    Aug 26, 2015 at 0:02
2

Holding configuration data like this externally to the application code is quite common. Since you have to persist this information somewhere a RDBMS is as good as anywhere, especially if the application is using the DB for "real" data already.

Having five tables for your putative five levels of menus is not a good idea. It is inflexible and you can reasonably expect this to change within the life of the system.

There are a number of ways to store linked sets of data in a relational structure. I found this post after a brief search. It discusses several possibilities. It will at least give you the vocabulary to research more thoroughly. The one which best suits your circumstances will depend on the number of rows you wish to store, the rate at which they change and the programming skill of your team.

Improve this answer
1
0

Generally treating menu items as data is a great idea. And, if the end users are managing the menuing like in a CMS then you can make a great argument for storing the menuing in the database. But if end users aren't dealing with it I would strongly consider dealing with it as data but in code rather than in an external store.

The basic mechanic here -- and I won't get specific as we don't have a platform indication -- would be to define a data structure for menu items according to requirements and then statically define the menu data as a global variable of an appropriate sort. This typically isn't horribly difficult to edit with modern development environments and you should have some continuious delivery worked out by now to get it in the client's hands quickly. You also get tracability of changes from source control.

That is all nice but the biggest advantage imho is that you don't have to pay the database "tax" if you will -- especially if the data is largely statically defined by developers anyhow. The tax comes in working out how to refresh the database with the right version of the data. It comes in having to have a database running to kick tires and test things. It comes in the defensive code you write because sue from accounting who has access to the DB server can now change things in the menu in unpredictable ways.

There is a lot less overhead and a lot less involved in just using an object graph over storing it in the DB. Plus, if you ever need to store it in the DB (or another external source such as a config file) you only need to change how it is loading into the object graph -- the client code remains the same.

Improve this answer
-1

You should NEVER keep those things in DB. There are other places where you can store the information. Pulling data from DB is expensive and much better solution would be to store it as XML or even separate class and including that object into other classes. Then you would only need to change the code on one place AND you would avoid torturing your DB.

Improve this answer
6
  • 3
    "Never" is a strong word. There are many situations where having a single source of the data across multiple servers is the correct answer - and that single source would be a database. In a suite of applications I worked on, the page could be served from a Java servlet, or a perl cgi, visual basic .asp page. These were from different web servers and machines. Changes to the navigation had to be simultaneous across all environments. The only sensible place to put this was in a database.
    – user40980
    Aug 25, 2015 at 21:02
  • There's also the case where the user is responsible for creating their own menu structure.
    – RubberDuck
    Aug 26, 2015 at 0:03
  • 1
    I can't imagine that it would be more efficient to store it as XML, unless the database were only for storing the menu data. Opening a file, building a document parser, and parsing the document would take much longer than executing a database query.
    – TMN
    Oct 14, 2015 at 17:51
  • @TMN : probably not. Database is typically a network request which are glacially slow compared to local disk results. Also, depending on the platform this is probably read once and cached so straight line speed don't matter so much.
    – Wyatt Barnett
    Oct 14, 2015 at 23:46
  • While I agree with Michael's "Never" comment, I think where Prc was going is that this sounds like a really clear case of "Over-Engineering". It is taking a simple problem with simple solutions and making it convoluted. I can guarantee with almost 100% certainty that this approach will turn into a maintenance nightmare once the original developers are off to greener pastures. With that said, there may be situations where the database approach is the only one that make sense, but I'd consider that the last resort option, not the "going into" initial plan.
    – Dunk
    Oct 15, 2015 at 14:11

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.