@wy315700 这种时候 DB2 ， Oracle 是恰当的，领域需求如此。

@zartouch ……你们可能偏金融交易，变化比较快。银行保险业变化非常慢。还是那句话，技术因为需要才需要，很多新技术坑确实不少，但是片面追求稳定而抛弃一些成熟的新技术，无视效率低下也很令人惆怅啊（望天

= =, 搞数据的原来这么不值钱...

@hantsy 所以说，还是根据项目需要而定。在范围内尽一切可能做到快速高效优雅。

@hantsy 没有很好的支持, 代码内部泛型的模板方法返回的时候靠配置文件绑定, 遇到过几次基础包装类拆包报错. 按最近几个帮人架的项目来看, 其实 JPA 比 MyBatis 开发周期更短, 需要操心的事情更少些, 某些场景下性能不如亲 SQL 的 MyBatis, 毕竟可以直接让 DB 分摊运算. '表'和'实体'只是手段而已, 纯 OOP 是优雅的, 不过优雅不是目的, 或者说在达到目的的同时尽可能的优雅 :).
同样的, 用什么持久方案都只是手段, 只不过现在可选择的手段多了, 只有金融业一千年不思进取,有些甚至还在用 DB2....这什么鬼.... RDBMS 比较看好 PostgreSQL, -野团 RMDBS 首选-
关于 boot 的话, 只是说, boot 创建 restful 应用更容易罢了. 而且约定大于配置有两面性, 熟悉 spring 的会觉得挺省事, 但是不利于新手的培养和提高, 因为新手不熟悉约定.

@hantsy …………金融公司一点都不土豪……我都不想呆这行了。说是找互联网架构师，把我忽悠进来……忽然又要调去搞传统核心架构。 restful 的应用，现在有 springboot 。本质上来说还是 spring 那一堆，但是从最近帮人搭了几套应用的情况看，从开发速度和效率上，跟更轻量级的框架不相上下，稳定性和布署便利性更胜一筹。 JPA 的性能不适合超过一定规模的系统，而且弹性有限，相对来说更喜欢自己钩 mybatis 这种更贴近 SQL 的持久化。

有这么几种思路和方法: 广义线性回归，非线性回归，样条。
分段处理其实就是样条，数据点少的时候用样条精度略差，比较难把握分段数据点临界点，数据多的时候运算速度快，拟合效果好（因为分段处理了），非线性回归拟合和计算都比较复杂。
广义线性回归求系数比较容易，系数就是最小二乘解

我，很在意！

看做啥了……简单 web 服务器的话直接买个 raspberry pi 刷个 arch 镜像就好了。

homelab 服务器的话，买个准系统，上 Debian/Ubuntu 。