大佬帮我看看这个表设计

• 資深大佬 : 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，可以存姓名，出生日期等，但是不应该存年龄，因为年龄是根据出生日期算出来的。