如果你不喜欢现在的专业就转，不转也可以自学或者选修 /辅修。现状很难改变，不过你如果真喜欢的话，自学比什么都强。

好像不好做增量，不过可以重新配置 maven 打一个 slim 包，lib 放在 jar 包目录下，每次替换 jar 包就可以了，大概只有几百 k

先搞个域名吧

@jedrek 健身教练现在都是马前吹，马后炮了

之前携程笔试有一个题目动规安排房间，要考虑大人和小孩，半小时没写出来

好像看到一个意思比较清楚英文表述
Limit Active Logins

可以强行用列式数据库的储存方式，不过，不适合再查询修改，只能一次导入或者导出

如果就几个页面，到时候还要商量接口，写接口文档，接口鉴权，一大堆问题，我是后端我也怼

如果是几个页面，确实没必要，就写 jsp 或者写 freemaker 不是挺简单
如果是一个很大的项目，那 SSR 是比较有利的，但是看样子你们的项目也不大，就不要给自己加工作量了

@d3vil
不跟你谈表的问题了。
首先，哪有业务量级呀，一个学校能有多少 QPS，单机都随便跑了。就算有再多钱，也要分析下具体情况，事实上，大部分业务都做不到大公司的量级。就算没有钱，没啥访问量的话，一个 join 查询也不能用了吗？

我也没有否认可以做到微信量级的可能。即使未来达到大公司量级，我们还有读写分离，集群，缓存这么多方法应对量级的增长，单单只是少用一个 join 我觉得有点削足适履了。

join 的性能没有这么差，特别是这种一对一关系，先不说有没有 300 万条，就算有 300 万条，如果你了解数据库的 b+树，就知道你指定一个 id 查是很快的，join 不过是以很快的速度再用 id 查一遍。而且数据库大多都有缓存池优化，包括用 hash 表。

设计规范只是为了将来好改动，如果是自己的项目，自己怎么爽怎么来。

域名加 SPF 记录添加 IP 白名单

@d3vil
写的不错哈哈。
一张表肯定不行的，无法应对业务的变化
两张表原则来说问题也不大，但是主要也是考虑到业务的实际情况。比如到时候学生和老师都要登录，那是不是还要加一个 id 判断的逻辑？或者由用户自己选择自己是老师还是学生，这样都是不友好的。所以本质上还是抽出一个成员的概念应对业务变化。
至于性能真的不是问题，就是一个简单的连表查询，主键索引速度很快的。还没到谈到什么预算的问题。不过具体到 ORM 可能配置起来还是有一点点麻烦。

mysql 官方例子就是这么搞的

对应到编程语言就是父类和子类的概念

拆一个公共表就行了
公共表是含义是成员，有每个人的基础信息
然后再是教师表和学生表，每个教师引用一个成员的 id，然后再添加老师专用字段

@fengci 我用阿里云的机器，结果一直给我掉线，然后登录的时候用第三方打码，一直错，就一直换验证码，两天钱就被花完了。但是我去验证码平台看都是对的，现在我放弃了，只能 先挂个飞猪和携程抢着。

@66beta 我试了 nova 的好像也是可以的，影响不大

@quwabcxyz 那就买吧，早买早享受