求思路：线下和线上会员的设计：报错
需求：
一个网站，有会员功能，但分为2种
线下会员：（不开放） 网站发指定会员卡和初始密码，比如会员卡都是手机号，密码都为123456 或者身份证 后 6位。
用此卡的帐号和密码可以登录网站，并享受打折服务。比如线下会员7折。
线上会员：（开放注册） 就是平时的会员功能发评论，等等基本会员功能。买东西跟游客一样不打折，但买东西的时候必须注册下会员才可以购买。
现在求数据库设计思路，是2个会员表单独分开，还是1个会员表用一个字段区分开来？
另外流程上，线下会员第一次登陆本站 需要2点操作，一这个初始密码和帐号只能登陆一次，登陆之后必须先修改密码才可以进行其他操作。 这点逻辑上怎么判断？
网站会员暂时都没有会员积分功能。
求成熟的案例，偶可以参考下。。。
大意就是普通会员和线下会员享受的东西大多都不一样，但不是简单VIP和普通会员的区分。
而且后台管理也存在问题。。求思路
写回答
-
最好一个表，要不然，会员和其他表的关联会出问题，比如会员买东西，会员发表评论，你总不能把评论表也搞成两个，购买记录也搞成两个表吧？后患无穷######搞个字段用来区分会员类型不就OK了？######一个表 用一个字段区分 线下,线上 你线上也需要注册的？
也就是说你的表的会员都有 帐号,密码字段 你在加个 初始密码是否使用 的字段就完了
至于你说的初始密码的逻辑//登录 if(线下){ if(!初始密码是否使用){ 初始密码是否使用 = true; } } ...执行登录######回复 @ZhangKevin2 : 判断不只是js判断，服务端也要判断 js是可以绕过的，除了问题就大条了######那我就登录的时候 判断 写个正则，凡是DOWN_开头的 帐户名ID都是线下的，否则就执行普通线上注册的用户登录？ 然后线上普通注册的 在注册的时候我在写个JS 限制不能以DOWN_开头注册就行了？ 那线下的帐户名和初始密码 是用EXCEL直接导入数据库会员表里？######引用来自“NikoG”的答案
搞个字段用来区分会员类型不就OK了？是啊，这个不就解决了吗？然后在付款的时候判断一下不就得了吗？反正那些行为线下会员优惠点的话，直接判断一下不就得了吗？ ######楼主考虑的复杂了吧，你这个情况就如上面提到的，用一个字段识别一下即可。另外，你最后说的VIP和普通会员，与你现在的情况其实是一个性质的。 就和论坛中有不同的用户组一样，不同的组不同的权限，而且也强烈建议你使用权限来区分各用户组所能进行的操作，这样也有利于你日后的扩展。给你一个参考的基础库结构： ID：int(索引) UserID：nvarchar(用户名) Password：nvarchar(密码) Int：int(boolean，是否完成初始化) Group：int(用户组)(另建用户组表，定义各组的权限) Rebate：int(折扣，也可在用户组中定义折扣率，此处的折扣率可用做针对单个用户的私有权限) ######回复 @psaux : 当然CHAR了，MD5之后固定的位数######password直接用char吧，事先确定了使用的hash加密方式和位数。######因为就一个线下和线上 2种情况，所以我觉得没必要搞个用户组来单独搞权限操作######如果线上会员和线下会员区别很大，建议分开表。只是要区分线上线下而已，可以只用一个字段识别。线下会员首次登录需要改密码使用登录次数字段+判断初始密码是否未更改来实现######回复 @ZhangKevin2 : 使用SQL的Left Join就可以。会员类型（线上线下）放置详细表######THANS，登录次数字段还没用过。。 其实还有一点很麻烦，一般会员，如果想登录块点都是分2个会员表，一个是 帐号和密码会员表用户登录，与之相关联的是会员详细信息表，比如会员的个人资料等等。 如此 如果结合线上线下的话 更纠结。。###### 显然分成两个表比较好 而且分成两个系统开发测试也快。 ###### 显然一个表，会员是一个对象，线上线下只是这个对象的属性。你的需求和苏宁电器的会员很类似，苏宁7000多万会员也分线下pos端申请和线上易购网申请，我们用的是一个表，这里存在一个线上线下同步问题，如果会员量小不用考虑都指向一个表就行。另外我们会根据地理区域分库，也就是水平分割，否则检索太慢。首次登陆改密码这个很多会员都有这样的需求，也可以用属性来区别。另外我说的会员一个表是逻辑上的一个表，由于会员有很多属性，都放一个表会影响性能，可以根据业务类型进行垂直切割。 ######引用来自“风飞雪”的答案
显然一个表，会员是一个对象，线上线下只是这个对象的属性。你的需求和苏宁电器的会员很类似，苏宁7000多万会员也分线下pos端申请和线上易购网申请，我们用的是一个表，这里存在一个线上线下同步问题，如果会员量小不用考虑都指向一个表就行。另外我们会根据地理区域分库，也就是水平分割，否则检索太慢。首次登陆改密码这个很多会员都有这样的需求，也可以用属性来区别。另外我说的会员一个表是逻辑上的一个表，由于会员有很多属性，都放一个表会影响性能，可以根据业务类型进行垂直切割。求详细点。。。 之前做的都是普通会员和VIP会员，ECSHOP二次开发等等，这次虽然项目不大也不难，但我还是想尽力做完善点，关键是我们公司策划烂到家了 天天改需求，线上线下会员肯定会有区别，但以后有多大区别还不晓得。 最烦的是有区别又有联系，如果分2个表 以后还要联表。 有些业务处理也麻烦。但如果放在一个表里，2种会员字段数也不一样，线上可能就5个，线下可能还要身份证什么的因为是发卡一对一发展现实中的会员，而且线下会员安全性要求更高 ######引用来自“ZhangKevin2”的答案
引用来自“风飞雪”的答案
显然一个表，会员是一个对象，线上线下只是这个对象的属性。你的需求和苏宁电器的会员很类似，苏宁7000多万会员也分线下pos端申请和线上易购网申请，我们用的是一个表，这里存在一个线上线下同步问题，如果会员量小不用考虑都指向一个表就行。另外我们会根据地理区域分库，也就是水平分割，否则检索太慢。首次登陆改密码这个很多会员都有这样的需求，也可以用属性来区别。另外我说的会员一个表是逻辑上的一个表，由于会员有很多属性，都放一个表会影响性能，可以根据业务类型进行垂直切割。求详细点。。。 之前做的都是普通会员和VIP会员，ECSHOP二次开发等等，这次虽然项目不大也不难，但我还是想尽力做完善点，关键是我们公司策划烂到家了 天天改需求，线上线下会员肯定会有区别，但以后有多大区别还不晓得。 最烦的是有区别又有联系，如果分2个表 以后还要联表。 有些业务处理也麻烦。但如果放在一个表里，2种会员字段数也不一样，线上可能就5个，线下可能还要身份证什么的因为是发卡一对一发展现实中的会员，而且线下会员安全性要求更高建议一个，如果按你的思路以后如果手机可以注册，为了区别手机注册的还要建个会员表？如果会员系统提供接口给别的系统用，你还要根据会员号去不同的表里查找？显然这样会给系统开发带来不必要的麻烦，这些一个字段就可以解决。现在存储设备如此便宜，为了减少系统复杂而浪费些空间非常值得。不同注册方法的会员字段不同，没有值得让它空着好了，不要太完美了。我们很多表都冗余了浮点和字符的字段，因为需求总是不断变化，时不时的要增加字段，这种冗余字段的方法带来了很多方便。设计系统和表结构首先一个原则就是尽可能的简单，然后再考虑性能最后考虑空间问题。如果会员有上百万建议切割表，将不常用的字段放在另一张表中。 一些拙见，不足之处还望不吝赐教。2020-06-08 16:18:16赞同 展开评论 打赏
版权声明：本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。
