\COPY <tablename> FROM '/somepath/somefile.txt' WITH (FORMAT csv, DELIMITER E'\x01') 。

用的商业数据库，和操作数据紧密相关的可以放存储过程。用的 mysql 之类的，还是在应用里做吧。

ubuntu 上用的 RIME，全拼 + 粤拼，感觉还是满意的。

postgresql 或者 mysql，即使要用 json 结构这俩也支持，尽量不用 mongodb。

一直用的肯辛通轨迹球，很方便。没有鼠标手的感觉了。当然只能办公用，游戏的话还是得鼠标。

还好吧，其实主要的还是数据仓库那一套。不过数据本身类型更得更多样、时效性要求更高、加上 ML 的玩法，还是有搞头的。

利益相关。推荐个 app：“完美志愿”，如果你认为它有价值，打算购买的话，可以用优惠码：666031。

推荐(利益相关)个自己所在公司的 app：“完美志愿”，作用就是帮助决策填志愿、选择学校专业。如果你认为它有价值，打算购买的话，可以用优惠码：666031。

利益相关。推荐个自己所在公司的 app：“完美志愿”，如果你认为它有价值，打算购买的话，可以用优惠码：666031。

利益相关。推荐个 app：“完美志愿”，如果你认为它有价值，打算购买的话，可以用优惠码：666031。

看你需求的类型， OLTP 的业务逻辑只要不涉及事务的，尽量在程序里维护； OLAP 的业务逻辑你不用 SQL ，数据正确性、一致性这些你自己程序维护，时间稍长都是坑。

数据库性能这个，如果只用过 MySQL ，真的就不要提了。

5 楼才是正解， 3 楼的不符合题意。

gnu parallel

Org mode

@billlee 在 groupby 前也许可以先对 iterable 先排个序？

建议将 excel 文件处理为文本文件，再用 sqlldr 将文本文件导入数据库。

@lonelinsky 嗯，你说得对。引入类型的话，就不能利用好外键了。方案一和一个中间表都不合适了。方案三，如果表 A 数据量大访问的话，也不合适。如果表 B 、 C 、 D... 可能增长的数量不多，那么方案二是好些。

根据时间建成分区表，加索引。

没看明白 2 ，为什么要建立多个中间表？只建一个中间表，存储表 A 与 表 B(C 、 D 、 E ...) 的关联不行吗？