“用户” SQL 表失控。寻找更好的方法
我编写和使用调查软件已经三年多了。它最初是一个简单的调查系统,带有一个基本的“用户”SQL 表,例如您可以在大多数 CMS 中找到的那样。我最初计划使用该程序两到三次,每次调查有 30 名左右的用户。
如今,该程序已经发展壮大,每月用于一到两次调查。一项调查可能有数百名用户,这使得表格非常长且令人困惑。
不过,我找不到比经典用户列表更好的方法。我想为每个调查创建一个新表,但我觉得它会带来问题。我现在所做的就是在调查完成后归档完整的 SQL 数据库,这对于现在来说足够方便,但当我必须快速找到旧调查的结果时,这将变成一场噩梦。
我相信我不是第一个遇到这个问题的人,并且很高兴知道您是如何解决它的。有一些最佳实践吗?
谢谢!
I've been programming and using a survey software for more than three years. It began as a simple survey system, with a basic 'users' SQL table, as you can find, for instance, in most CMS's. I initially planned to use the program two or three times, with 30 users or so for each survey.
Today, the program has grown and is used for one or two surveys every month. A survey may have hundreds of users, which makes the table awfully long and confusing.
I can't find a best way than a classic user list, though. I though of creating a new table for each survey, but I feel it's asking for problems. What I do now is to archive the complete SQL database when a survey is finished, which is convenient enough for now but will turn into a nightmare when I'll have to quickly find the results of an old survey.
I'm confident I'm not the first one to encounter this problem and would be happy to know how you solved it. Are there some kind of best practices for it?
Thanks!
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
一种解决方案是维护两个表。用户和Users_History。
调查完成后,您可以将数据移至 users_history。这样,影响应用程序性能的数据库将保持在可管理的范围内。出于分析目的,历史表中始终提供数据。
One solution is to maintain two tables. Users and Users_History.
Once a survey is complete, you can move the data to users_history. That way, DB that affects app performance would stay within a manageable size. For analysis purpose, data would always be available in history table.
如果每个调查的用户集不同(两个调查中的同一个人将拥有两个不同的用户帐户),您可以向引用调查表的
users
添加一列。如果您想要允许未与调查关联的用户,请允许调查引用为 NULL 并将外键设置为
ON DELETE SET NULL
。当您需要对用户表进行操作时,请使用该列仅获取属于感兴趣调查的一部分的用户。
If the set of users for each survey is distinct (the same person in two surveys would have two different user accounts), you could add a column to
users
referencing the surveys table.If you want to allow users that aren't associated with a survey, allow the survey reference to be NULL and set the foreign key to
ON DELETE SET NULL
.When it comes time for you to operate on the users table, use the column to get only the users that are a part of the survey of interest.