我们如何将所有页面系统对象连接到一个模式中？
我有一个页面。页面有表格。表单有字段。字段有值。 页面还有菜单、文本、标签。与表单、字段、值共享。 有些文字是链接。有些菜单是消息窗口。
我正在尝试将它们结合在一起，以便我可以实现用户跟踪（链接跟踪、字段跟踪、页面跟踪等）。我认为策略是这样的：
1) 为每种类型（链接、页面、字段、值、表单、文本、标签、菜单、窗口）创建一个查找表。
2）使用FK将所有表关联在一起？ （这是我迷失的地方，哪些 FK 与谁相关，以及这种方式是否有意义，因为如果我每次在页面加载时必须连接 5 个表来提取信息并写入从这些表中读取的活动表，则会影响性能用户）。那么这在现实世界中是如何实现的呢？
一些数据（例如字段值查找）来自不同的表，例如“城市名称”、“公司名称”等。所以这些不能在 1 个表中。
该网站是一个社交网络。正在为网站和移动应用程序构建用户跟踪，因此通用表。平台是php/mysql。
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 message 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.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
这是一个基本的表格设计问题。
第一个概念。就像东西放在一起放在桌子上一样。所以你至少有页面、表单和字段的表格。表单具有到页面的 FK，字段具有到表单的 FK。一旦我们解决了这个问题，作为后续问题，价值观可能会更好。
菜单通常以层次结构形式存储在一个表中，通常为 menuId、parentId、text、link。
到目前为止，这给了我们四个表，其优点是组织良好，但随后我们面临着在每个页面加载时使用所有这些连接组装所有这些表的问题。
那么数据的稳定性如何呢？如果高度稳定，您可以预先生成大量 HTML 到缓存文件中，这些文件仅在数据更改时更改。如果数据每周更改一次或类似的情况，那么性能会更高。如果数据每分钟都在变化，您就必须保持动态。
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.