人间不值得

Kindle+一个 Webapp （前台）＋手机控制端（后台），还能跨设备跨平台，结帖。

搞个短信验证码登录不就得了

@bestkayle 感觉你在说我啊，虽然我学历也不是特别低，技术也学得很快，但目前的确很烂...还有严重拖延症，唉，真得改改阿

“ id 判断的逻辑”是什么？不同的角色登录，去操作不同的表就可以了，然后让前端后端在代码上配合做区分，我并不认同你所说的“不友好的”，因为我就举个例子吧，阿里云有免费邮箱和企业邮箱，他们都是邮箱吧？但是他们的登录地址却不同，一个是 mail.aliyun.com ，一个是 qiye.aliyun.com ，用户登录不同的邮箱竟然还要跨子域耶！这是不是也是不友好呢？我觉得不能有这样的强迫症= =。
https://ws2.sinaimg.cn/large/006tNc79ly1fyznwfq9nwj30jq0vemzs.jpg
你要想在前端做好看一点，不要有类似上面的选择框，你就可以学阿里邮箱用不同子域管理不同的角色的业务（学生和老师的职能、业务的确是有很大的不同的），要么你就在前端做区分，对一个问题钻牛角尖，只会让自己手足无措的，而永远无法到达一个彼岸的，也没有一个实际的方案能给到你。
简单的连表查询...一个再简单的操作，面对起以后业务的量级，都会有极明显的差异，比如一个表有三百万的数据，你要进行三百万条记录的 Join，这和单表查询的绝对耗时能比吗？肯定会有性能差异的。
那没谈到预算的问题，那就什么方案都行呗，那不就是做外包一样的，怎样实现来得快来得简单，就怎样做，那随便怎么做都行的，实现的方法那么多种，随便选个呗，要是有预算，那就不一样了。要是你不考虑性能，那你就往规范的方向做呗，选择规范设计。

#12 打错字了，教室改为“教师”。想在中型以下那一行多加一句：如果业务不大，其实设计两张表真的是最优选择，多一个 Table 真不会多占用多少空间= =好好想想吧，怎么会有“分开设计，那么大多数属性都是重复的，这样似乎较为浪费空间”这种说法？道理在哪里？赐教一下？这到底怎么浪费空间了？只是另外腾出一个动态空间来存放东西而已，只是多贴了一个标签而已，多少条记录就是多少条记录的空间啊，就是多了一个“标签”的空间而已啊，不过遥想我们当初学 SQL SERVER 2008 的时候，创建一个数据库好像要为两个文件（记得好像是 mdb 和 log 文件）给定一个固定的大小....MySQL 应该不存在这样的吧？空间都是动态增长、占用的吧？

所以初步的结果就是：
如果楼主的业务如果是中型以下，可以选择设计两个表，也就是学生一张表，教室一张表。
如果楼主的业务如果是中型以上，那么则应该规范设计，将公共字段独立为一张表，然后每一个 Role 去创建一个新表来存储 its own distinct filed。

分开表，并不会占用更多的空间，因为每个人就是占用一条记录；
不分开表，也就是楼主所说的前者的实现方式，这是最 Low 的实现方式，弊病你自己也明白，不仅仅会造成空字段，并且会在写代码上造成不方便；
#5 楼所说的父表与子表的方案，这个方案在逻辑上是最具有层级关系的，就是它在逻辑性、系统性这两个方面来说，是最好的，最规范的。（适合大型、复杂、非常需要考虑扩展性的业务），但是他的方案不管是在空间上、时间上（查询），都是最为难受的选择，想要整个系统的高要求，不管是空间上还是时间上，你都无法避免需要进行牺牲，所以，楼主的问题其实应该自己告诉自己，因为你最明白你这个业务的预算是多少，做一个工程，你自己得做评估、预算，有了这个，别人才能够根据你的实际情况来推荐具体的解决方案，否则，便是无源之水，无根之木。

@wdytoya 看到了，多谢

等一个入口？