超级会员是要付费的 比如100元一个月
那么我建表的时候应该怎么比较科学呢？
15 个解决方案
#1
就目前的描述，建一个会员信息表，有字段区分付费和普通会员，再建一个付费信息的日志表，记录每次会员付费的记录
#2
那我每次判断他是普通会员还是超级会员应该是判断付费的到期时间 还是根据字段来判断
比如他付费了 现在会员字段里是超级会员 如果到期了 那他字段超级会员就更新成普通会员？
那岂不是每次登录的时候都要判断一次他是不是到期了？
#3
到期设置应该有另外的服务程序后台每天定时判断吧，登录时只检查当前状态
#4
一般都是这样设计的吗？我感觉每天定时判断好麻烦
#5
如果访问量不大的话，放到登录里做过期判断也可以，但增加了登录处理的复杂度了
#6
可以建会员表,会员级别表。
#7
有一个表，记录普通会员和超级会员，各个会员的价格，另外一个表记录用户，然后用第一个表的ID来做会员区分
#8
我怎么判断超级会员是否到期呢？ 到期时间字段应该放在哪呢？
#9
如果搓B一点的话你就可以在User表里加一个列来记录会员到期时间，到时候系统登录的时候可以查询出来做比较
或者另加一张表，用user id，vip id 和开始时间，结束时间来做记录也行
#10
这样的话每次登录就需要判断一次 不如直接判断到期时间不是更好？ 还是说这样做有什么弊端吗？
#11
这个要具体看功能吧！你普通会员 会不会升级成 超级会员？ 或要是一个用户 充了普通会员后 再充值超级会员，时间又是要怎么定的，是先使用超级会员 时间使用完后再使用普通会员 还是直接全部转成超级会员 或其他什么的、
具体还要要根据业务需求吧！
具体还要要根据业务需求吧！
#12
所有注册用户都是普通会员 超级会员只是普通会员付费后变超级会员
#13
那么如果产品经理过2周以后又确定“并不需要每次登录都判断是否到期”你又怎么半？业务需求是千变万化的，程序员要本着基本的原则来设计程序，而不是用程序员的脑袋来臆断业务。说白了，要想知道什么是真正的业务需求，先把自己从技术出发的东西“放下”你就开始明白了。
像你这里反复纠结了2遍的“每次登录就判断一次是不是到期”这就是你找的一个借口，你应该首先告诉自己“即可能需要判断到期、也可能不需要到期。 我从技术上都能做到”。你告诉自己这个，才刚刚开始理解技术和业务的辩证关系。而不是现在技术的空想中。
#14
#7 楼是本着一个比较规范的设计原则来设计表结构的。他所说的，比如说“用户”表有20个字段，表示了所有用户的通用数据，例如用户的昵称、用户的密码（签名）、用户最后一次登录时间和地点、用户总共在线时长、其它用户画像资料。而“普通会员”表（除了id以外）可能有5个字段，包括“手机号、自定义头像、注册地点”等。而“超级会员”表（除了id以外）可能有6个字段，包括“身份证、省份证认证信息、到期时间、会费、等级、充值”等等。
由此可见，普通用户可能会从5个字段将来扩展为20个字段，超级用户将来也可以从6个字段扩展为30个字段，用户表将来可能从20个字段扩展到30个字段。它们各自有各自的用处。
按照你的说法，普通用户就是用户的扩展，超级用户本身可以是普通用户的扩展。因此就可以分为3个表。
至于说登录，在一定的流程中你需要验证用户的密码，再另外的流程中你需要获取普通用户的自拍头像，在其它流程中你需要给那些即将到期的超级用户进行提醒，应该分别设计。没有什么千篇一律的代码可以做到一切业务需求，业务是千变万化的，该怎样分割表就怎样分割表。在成千上万的应用中总结出来的数据库范式，可以应对大部分应用需求变化情况，总比你任性地分表要好一点。
由此可见，普通用户可能会从5个字段将来扩展为20个字段，超级用户将来也可以从6个字段扩展为30个字段，用户表将来可能从20个字段扩展到30个字段。它们各自有各自的用处。
按照你的说法，普通用户就是用户的扩展，超级用户本身可以是普通用户的扩展。因此就可以分为3个表。
至于说登录，在一定的流程中你需要验证用户的密码，再另外的流程中你需要获取普通用户的自拍头像，在其它流程中你需要给那些即将到期的超级用户进行提醒，应该分别设计。没有什么千篇一律的代码可以做到一切业务需求，业务是千变万化的，该怎样分割表就怎样分割表。在成千上万的应用中总结出来的数据库范式，可以应对大部分应用需求变化情况，总比你任性地分表要好一点。
#15
对于扩展/继承的表结构，在最*的表（这里就是用户表）的id旁，可以记录一下“最终类型”。而在子表中不需要记录最终类型。因为子表通过 id 跟最*的主表关联，不应该有冗余的字段。
#1
就目前的描述，建一个会员信息表，有字段区分付费和普通会员，再建一个付费信息的日志表，记录每次会员付费的记录
#2
那我每次判断他是普通会员还是超级会员应该是判断付费的到期时间 还是根据字段来判断
比如他付费了 现在会员字段里是超级会员 如果到期了 那他字段超级会员就更新成普通会员？
那岂不是每次登录的时候都要判断一次他是不是到期了？
#3
到期设置应该有另外的服务程序后台每天定时判断吧，登录时只检查当前状态
#4
一般都是这样设计的吗？我感觉每天定时判断好麻烦
#5
如果访问量不大的话，放到登录里做过期判断也可以，但增加了登录处理的复杂度了
#6
可以建会员表,会员级别表。
#7
有一个表，记录普通会员和超级会员，各个会员的价格，另外一个表记录用户，然后用第一个表的ID来做会员区分
#8
我怎么判断超级会员是否到期呢？ 到期时间字段应该放在哪呢？
#9
如果搓B一点的话你就可以在User表里加一个列来记录会员到期时间，到时候系统登录的时候可以查询出来做比较
或者另加一张表，用user id，vip id 和开始时间，结束时间来做记录也行
#10
这样的话每次登录就需要判断一次 不如直接判断到期时间不是更好？ 还是说这样做有什么弊端吗？
#11
这个要具体看功能吧！你普通会员 会不会升级成 超级会员？ 或要是一个用户 充了普通会员后 再充值超级会员，时间又是要怎么定的，是先使用超级会员 时间使用完后再使用普通会员 还是直接全部转成超级会员 或其他什么的、
具体还要要根据业务需求吧！
具体还要要根据业务需求吧！
#12
所有注册用户都是普通会员 超级会员只是普通会员付费后变超级会员
#13
那么如果产品经理过2周以后又确定“并不需要每次登录都判断是否到期”你又怎么半？业务需求是千变万化的，程序员要本着基本的原则来设计程序，而不是用程序员的脑袋来臆断业务。说白了，要想知道什么是真正的业务需求，先把自己从技术出发的东西“放下”你就开始明白了。
像你这里反复纠结了2遍的“每次登录就判断一次是不是到期”这就是你找的一个借口，你应该首先告诉自己“即可能需要判断到期、也可能不需要到期。 我从技术上都能做到”。你告诉自己这个，才刚刚开始理解技术和业务的辩证关系。而不是现在技术的空想中。
#14
#7 楼是本着一个比较规范的设计原则来设计表结构的。他所说的，比如说“用户”表有20个字段，表示了所有用户的通用数据，例如用户的昵称、用户的密码（签名）、用户最后一次登录时间和地点、用户总共在线时长、其它用户画像资料。而“普通会员”表（除了id以外）可能有5个字段，包括“手机号、自定义头像、注册地点”等。而“超级会员”表（除了id以外）可能有6个字段，包括“身份证、省份证认证信息、到期时间、会费、等级、充值”等等。
由此可见，普通用户可能会从5个字段将来扩展为20个字段，超级用户将来也可以从6个字段扩展为30个字段，用户表将来可能从20个字段扩展到30个字段。它们各自有各自的用处。
按照你的说法，普通用户就是用户的扩展，超级用户本身可以是普通用户的扩展。因此就可以分为3个表。
至于说登录，在一定的流程中你需要验证用户的密码，再另外的流程中你需要获取普通用户的自拍头像，在其它流程中你需要给那些即将到期的超级用户进行提醒，应该分别设计。没有什么千篇一律的代码可以做到一切业务需求，业务是千变万化的，该怎样分割表就怎样分割表。在成千上万的应用中总结出来的数据库范式，可以应对大部分应用需求变化情况，总比你任性地分表要好一点。
由此可见，普通用户可能会从5个字段将来扩展为20个字段，超级用户将来也可以从6个字段扩展为30个字段，用户表将来可能从20个字段扩展到30个字段。它们各自有各自的用处。
按照你的说法，普通用户就是用户的扩展，超级用户本身可以是普通用户的扩展。因此就可以分为3个表。
至于说登录，在一定的流程中你需要验证用户的密码，再另外的流程中你需要获取普通用户的自拍头像，在其它流程中你需要给那些即将到期的超级用户进行提醒，应该分别设计。没有什么千篇一律的代码可以做到一切业务需求，业务是千变万化的，该怎样分割表就怎样分割表。在成千上万的应用中总结出来的数据库范式，可以应对大部分应用需求变化情况，总比你任性地分表要好一点。
#15
对于扩展/继承的表结构，在最*的表（这里就是用户表）的id旁，可以记录一下“最终类型”。而在子表中不需要记录最终类型。因为子表通过 id 跟最*的主表关联，不应该有冗余的字段。