大佬帮我看看这个表设计

[noobma]

现在要做会员卡功能，有 2 种会员卡，次卡、储值卡，下面是我的设计

次卡表

id	次数

储值卡表

id	金额

用户会员卡表

user_id	会员卡 id	卡类型	剩余次数	剩余金额

我想着查询的时候方便，就把 剩余次数 和 剩余金额 放到用户会员卡表里面了，要是次卡 剩余金额 就为null，要是储值卡 剩余次数 就为null，以后如果要再加一个其他类型的会员卡，那我这个用户会员卡表可能又得加字段。

大佬们帮我看看这样合理吗？比较常见的做法是什么样的

[kaka6]

纯用关系表的话，正常就是这样设计
想要更灵活组合下 nosql

[tesguest123]

null—empty ‘,大表里少了些状态字段。其他类型不用加字段了吧，直接绑定类型就行了吧。我也不懂

[cmdOptionKana]

就不要剩余次数 和 剩余金额了吧，主要是方便不了多少。甚至可以说更麻烦了，因为要维护这两个数字与另外两个表的一致性。

[mkfs]

为什么我觉得用户会员卡表可以不要。
卡表里面各自加一列 user_id，要获取一个用户的各种卡，到各个表里面各一个简单 SELECT 就好了。
如果实在是想一个查询得出用户会员卡表这种格式，用 UNION ALL 。

[medivh]

1. 表应该有数据无关的主键，考虑日后多对多的扩展性；
2. 应该记录消费记录，而每条消费记录都需要时间戳、操作人员这类的信息，一定会用得到；
3. 多考虑一些业务上的幺蛾子需求，比如说用户需要在两种卡之间转换之类的，会对你的表结构带来什么影响；
4. 给主表加上删除标记（或者直接用一个 bitmask 做可扩展状态标记），创建时间，更新时间等扩展列；

[justfun]

你这样设计不科学 。建议了解一下数据库设计范式 https://www.cnblogs.com/linjiqin/archive/2012/04/01/2428695.html

[netnr]

范式➕冗余 ，别太精炼

[uiosun]

你这储值业务的字段，冗余到会员卡表的意义何在？

要么储值业务直接融到会员卡表（储值会员卡表，一张解决问题）
要么就做外键关联，Redis 缓存你需要冗余的高频字段

[fansfans]

用户会员表不要存储次数和金额吧 万一一个用户两张表咋整

[hyqCrystal]

我咋觉得一张表就行了勒 有何缺点吗

[shanghai1943]

我觉得应该是一张卡表和一张用户和卡的关系表就可以了。
卡表：id type 金额 次数；
关系表: user_id, card_id, card_type, 剩余金额，剩余次数

[JohnH]

我有个类似形态的项目，设计表如下
- 会员表 users
...
- 卡类型表 cards
name,type[1:次卡,2:折扣卡],amount[总次数],money[总金额]
- 会员卡表 user_cards 一对多
user_id,card_id,card_type,amount[剩余次数],money[剩余金额],created_at...

把所有卡混在一个表里了，会员获得一张或多张卡，消费时选择某种卡来消费

[JohnH]

跟楼上如出一辙[汗]

[yzbythesea]

用户会员卡表里只有 user_id, 会员卡_id

次卡表 和 储蓄卡 表里分存 对应卡的所有信息

要不然你每更新一次卡的信息，就要锁住两个表写。

[wozhizui]

不符合 [第二范式] 来着？剩余次数和剩余金额和其他表相关了，可以计算出来的列，不应该存到用户的数据表中。
比如一个自然人的信息表 person，可以存姓名，出生日期等，但是不应该存年龄，因为年龄是根据出生日期算出来的。