Database design for Magazine website with flexible horizontal menus

Why not have a single page deal with the content?

Just call Page.aspx?Issue=4&Page=4

Then in your code you know it's the 4th Issue and they want Page 4, then you can have code in the Page.aspx (.vb or .cs) which translates that and then decides on the layout.

So E.g.

Page.aspx?Issue=4&Style=Article&Content=5

So in the code you could then go, Okay it's issue 4 get the database entries for Issue 4, okay they want Content ID 5 from Issue 4, then put in the style of an Article.

This means you don't have to add extra pages into the database type you can simply just add content as you wish and the item which generates the URLs to access the content just need to show all the content.

I think you need to re-evaluate your database schema.For example, I would have a table called "ParentMenuItems"

This table would include all Top Menu Items (Home, About Us, Issues, etc), and have the text for child menus.Then you need to have a ChildMenu table that has relations to your Parent Menu items.

ParentMenuItems:==============================================================ID       | LinkText      | LangID     | Other Properties==============================================================1        | Home.aspx     | 1          | blah blah blah2        | AboutUs.aspx  | 2          | blah blah blah

Then, you could have another table called "ChildMenuItems" like this:

ChildMenuItems:===============================================================ID   | LinkText       | LangID |  ParentID  | Other Properties...===============================================================1    | PageOne.aspx   | 1      | 2          | blah blah blah2    | PageTwo.aspx   | 2      | 2          | blah blah blah

The code could work like this:

SELECT * FROM ParentMenuItems - //SQL to get Items

Then, write some foreach code to enumerate the SQL results

foreach(var ParentMenuItem in ParentMenuItems){     //Get ParentMenuItem ID, run SQL select on child menu items, Example:    //SELECT * from ChildMenuItems where ParentID = ID.FROM.PARENT.RESULT    // Now you have all the child menu items, foreach those and add to repeater control}

I hope this helps.Let me know if you have questions.

TIP: Entity Framework will make very light work of this.

I'm not sure I understood what you need, but I'll assume you want to create a menu for the whole system, and not a menu for each magazine, right?

If so, I think you are looking to the wrong problem: The problem is not the database schema, but the concept that your menu should be automatically filled by N different tables that have no predefined standard.

I would create a menu table - and make magazinepages and menu two distinct tables: If you are creating an CMS-like system, you'll probably have a page where I can edit categories, issues and - why not - menu entries, completely apart from any other tables.

Also, I'd create a "tags" system, where all my news and issues could be "tagged" instead of put in a exclusive category. It would make possible to have a news that talks about politics and culture at the same time. Then, instead of directing user to lots of different pages.aspx, you'd use a content.aspx?tag=politics. When creating tag, I'd have the option to add this tag to menu table, under "news", "issues", etc. Same for category and issues.

If it doesn't fit your needs, you can try those options - but all other solutions than a specific table for menu entries trows a "warning, future problems detected" in my brain:

1 - create a menu table, a stored procedure that fills this table by following specific rules and then triggers on tables like "category" that would truncate and call the stored procedure, rewriting menu every time content changes (sounds like a quick fix to me)

2 - Add a "submenu_table", "submenu_field", "submenu_condition" etc to magazinepages and use dynamic sql to select data (something like Set @SQL='Select '+ submenu_field + ' from '+ submenu_table + ' where ' + submenu_condition; Exec(@SQL)) (another quick fix, heavy and probably slow query)

(edit:)3 - there's also hierachyId field in sql 2008 and above ([http://blogs.msdn.com/b/manisblog/archive/2007/08/17/sql-server-2008-hierarchyid.aspx])1