在整个应用中， v 友是怎样去禁用某个用户的

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

› MySQL 5.5 Community Server

› MySQL 5.6 Community Server

› Percona Configuration Wizard

› XtraBackup 搭建主从复制

Great Sites on MySQL

› Percona

› MySQL Performance Blog

› Severalnines

推荐管理工具

› Sequel Pro

› phpMyAdmin

推荐书目

› MySQL Cookbook

MySQL 相关项目

› MariaDB

› Drizzle

参考文档

› http://mysql-python.sourceforge.net/MySQLdb.html

这是一个创建于 1367 天前的主题，其中的信息可能已经有所发展或是发生改变。

一直好奇这么个逻辑
v 友们是怎么去禁用某个用户的？
直接在表里面加个 status 标记吗

但是这样感觉需要整个团队去了解这个字段，不然有个新来的查询的时候忘记写 status 条件了就会出现尴尬的情况

我觉得肯定有更好的方案只是我没想到。

status

禁用

字段

标记

17 条回复 • 2021-02-20 00:48:53 +08:00

felixcode

2021-02-16 14:42:54 +08:00 via Android

有个 blocked 字段不就行了，True False

also24

2021-02-16 14:44:28 +08:00

禁用状态本来就是业务相关的，特别是此用户产生的内容能被其他用户查看的时候。

比如说，一个用户被禁用后：
用户自己是能登陆但不能操作，还是直接禁止登录，还是等同于删号不存在？
用户的个人信息页是一切如常，还是加封禁标记，还是屏蔽内容，或者等同于删号不存在？
用户已经发出的评论、内容等，是一切如常还是进入锁定状态，或者直接删除相应内容？
用户已经的评论被嵌套评论，内容被评论或点赞的记录，是否还有效，操作人那里是否还能看到记录？
用户已产生的订单是否还可以操作，如果有未完成的订单是否要自动取消？
用户的私信对象是否还能查看历史记录，是否还能回复私信？
用户是否存在剩余的虚拟资产，是否提供处置方式？

我觉得这个『禁用』，还是需要产品需求方先明确定义了，才能更好的设计如何实现。
而一旦将相应的业务需求明确定义了，应该也不会存在 status 忘查询的情况（除非需求方先忘了）。

imn1

2021-02-16 15:00:48 +08:00

鉴权是必须执行步骤，如果忘了写，就是工作失误了，除非他写的部分无须鉴权

不用考虑谁有没有写的问题，而是考虑有没有手册说清楚，以及有没有相关的工作要求
然后用什么，怎么用，要看业务逻辑

xuanbg

2021-02-16 15:08:43 +08:00

用户身份认证 /鉴权有统一的入口，不存在别人不了解造成失误的情况。

heyjei

2021-02-16 15:13:13 +08:00

接口封装好后给别人调用啊。

340244120w

2021-02-16 15:26:58 +08:00 via iPhone

状态，创建日期，修改日期是除了 id，用户名，密码之外行业默认的必备字段了。

所以，有的人不知道这种常识，要改变的是他而不是系统🦆

YouLMAO

2021-02-16 16:06:38 +08:00 via Android

V
站被封是随机重置密码

所以

只要用 Gmail 再来重置密码，立刻复活

不要作恶，小心出门被车撞死

xxbutoo

2021-02-16 18:39:45 +08:00

@xuanbg 比如用户 id 2 的 status = 1 的表示禁用

然而有个业务类似这样 $user->where('id', 2) ->find() 吧数据查出来了

CEBBCAT

2021-02-16 20:18:31 +08:00 via Android

@YouLMAO 兄弟你想想这个叫“被封”吗？

YouLMAO

2021-02-16 20:22:43 +08:00 via Android

@CEBBCAT IP 会被封的，需要换个机场，重置密码

xuanbg

2021-02-16 22:38:20 +08:00

@xxbutoo 提供用户查询接口啊，怎么能应用自己查数据库呢？都 2021 年了，该把微服务搞起来了呀。不行就直接用我的吧……自己去我的 github 找，我就不广告了。

badcode

2021-02-16 22:50:38 +08:00

规则一旦写死
有些人就按照这个来各种破坏
还给了他 BB 的理由

---------------------以上来自 v2

个人认为，不太可能让这个规则明示，
换一句话就是，这个规则在管理层内部或者站长会根据当前的情况而定。

also24

2021-02-16 22:54:09 +08:00

@xxbutoo #8
所以说还是要看业务需求啊……

就算一个码农注意到了 status 字段，那对这个字段的用户该怎么处理，还是不知道啊。
如果需求方没有明确说明，这个业务对被封用户要怎么处理，那码农怎样越殂代疱来决定呢？

aristolochic

2021-02-16 23:40:56 +08:00

上面说到了微服务
其实单体应用也要拆分模块提供接口的
不明白为什么认为只有微服务才能解耦
任何系统大起来之后里面也不能是糊糊叭
微服务一开始就注意这些，可单体应用老油条们也各有各的解决方案
Java 的 Spring 那些不有业务层吗，不是用来干这个的？
Rails 充血模型，一开始写在模型里，后来复杂起来写在 Concern 里，再复杂一点学 Java 用 Service Object，等成熟了抽离出 Engine，就成了一个完整的独立模块
Django 的 App 应该也可以做这些（但我不太熟不好说明）

这又不仅仅是 Ban 一个用户如何实现的问题
其他涉及数据敏感的地方，也要谨慎啊

就算内部是一团浆糊，维护者需要直接访问数据，
但还有手册吧？虽然确实可能“忘记写什么东西了”，
要是 CodeReview 没有铺开也可能发现不了
但这个不是还有测试管着呢嘛
怕什么怕

chouchen

2021-02-17 11:56:38 +08:00 via iPhone

这种最简单的字段都能漏的人，他写的代码你敢用吗？

dorothyREN

2021-02-17 15:07:01 +08:00

密码前面加个！

xxbutoo

2021-02-20 00:48:53 +08:00

@felixcode 不是啊同学，blocked 字段和 status 字段有什么区别