How do we tie all the Page system objects together in a schema?

I have a page. Page has forms. forms have fields. Field have values. Page also has menus, text, labels. Which is shared with forms, fields, values. Some of the text are links. Some of the menus are mess开发者_开发知识库age windows.

What I am trying to do it tie it all together so i can implement user tracking (link tracking, field tracking, page tracking, etc). I assume the strategy is like this:

1) Create a lookup table per type (links, pages, fields, values, forms, texts, labels, menus, windows).

2) use FK to relate all tables together? (This is where i am lost on which FKs relates to whom and if it makes sense this way because if i have to join 5 tables eachtime on page load to pull info and write to activity tables reading from these it will effect performance with lot of users). so how is this implemented in the real world?

Some data like field value lookups comes from different tables like "city names", "company names"etc. So these cannot be in 1 table.

The website is a social network. User tracking is being built for the website and mobile app, so common tables. Platform is php/mysql.

This is a basic table design question.

First concept. Like things go in tables together. So you have tables of Pages, forms and fields at least. Forms has FK to Pages, Fields has FK to Forms. Values might be better as a follow-up question once we have this sorted out.

Menus are usually stored as a hierarchy in one table, typically menuId, parentId, text, link.

So far this gives us four tables, with the advantage of having it well organized, but then we confront the issue of assembling all of this on every page load, with all of those joins.

So how stable is the data? If it is highly stable, you can pre-generate lots of HTML into cache file that change only when the data changes. If the data changes once/week or something like that, this will be much more performant. If the data is changing minute-by-minute you have to stay dynamic.