Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

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?

share|improve this question
    
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 '14 at 9:35
    
ACtually I am a part of featured time in AGile env, so I am expected to deliver that ;) –  user970696 Jul 27 '14 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 '14 at 12:32

3 Answers 3

up vote 6 down vote accepted

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).

share|improve this answer
    
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 '14 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 '14 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 at 0:02

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.

share|improve this answer

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.

share|improve this answer
2  
"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. –  MichaelT Aug 25 at 21:02
    
There's also the case where the user is responsible for creating their own menu structure. –  RubberDuck Aug 26 at 0:03

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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