我的电子表格使用铁律：别用
My Rules for Using Spreadsheets
我的核心规则很简单：别用电子表格。过去十几年，我不得不分析数十个由工程公司发送的 Excel 文件，它们往往混合了数据、分析和报告格式，导致公式复杂难懂、数据分散且缺乏统一标准。这种点击拖拽的便捷性像塞壬的歌声，极易诱导人们做出糟糕的组织决策并引入错误。面对像 US baby names 这样超过百万行的数据集，Excel 和 Numbers 的行数限制更是捉襟见肘。相比之下，利用 Python 的 Pandas 库或 SQLite 数据库，将逻辑与数据分离，不仅能轻松处理海量数据，还能通过清晰的代码逻辑避免人为失误。
我将当今应用程序构建电子表格的便捷性视为塞壬的歌声，它会引诱我触礁。
HN 评论区
57- sgarland
用 Excel 既能干出令人毛骨悚然的事，也能干出令人惊叹的事。三星奥斯汀晶圆厂（至少在 2020 年左右）就用它来生成机器标签。这些是纸质卡片，尺寸大约 2 英寸 x 4 英寸，上面包含以下信息：
* 机器名称/编号
* 所属技师的姓名、班次、照片和电话号码
* 所属工程师的姓名、班次、照片和电话号码
我们团队大概有 250 台机器，分布在 4 个班次。只要任何团队有人进出，我们就得重做卡片，这通常还涉及重新平衡工作量。幸运的是，有人写了一个 Excel 宏，连接到存有员工信息的 MSSQL 数据库（据我所记，里面没有薪资等机密信息；我觉得那是用来生成工牌的），自动拉取所有所需字段并填充模板。打印出来，剪开，贴上去，搞定。
我在那里的贡献是实现了一个简陋的路径优化方案，试图将连续的机器分配给同一位技师，以尽量减少他们每周巡检时的步行距离。这方案多少有点用；反正比没有强。
- alexandrehtrb
1) 今天我才知道 Excel 里还有“命名单元格”这玩意儿。
2) Excel 对技术人员和非技术人员都很友好。哪怕 10 岁的孩子也能学会 Excel（我大概那个年纪还是学生时就第一次用了）。
3) 1,048,576 行对于 99% 的 Excel 使用场景来说已经绰绰有余了。
4) Excel 可以连接外部数据源，比如数据库和 API，由它们执行更繁重、更复杂的数据操作，从而把这部分责任从电子表格中剥离出去。SQL 查询和过程调用都可以嵌入到 Excel 电子表格中。
5) 有些 Excel 技能，比如命名单元格和 VBA 函数，大多数人都不知道。关键在于把这些知识分享给他们，让他们能做出更好的电子表格。
- LMKIIW
humble 的电子表格是我们这一代人最稳健的数据分析工具，而作者提供的两个例外情况（适合屏幕显示的数据、临时存储）却忽略了许多本贴评论中提到的各种用途。
在我看来，其核心价值——正如其他人所说——在于它能分享给非技术人员。
- sherburt3
逐条检查 Excel 报表里的公式简直让人发疯。通常我在检查别人的工作是否有误时，会随机抽查某一列的几个数值，手动计算看看是否对得上。要么就直接自己在 Excel 里把那个步骤重做一遍，看输出结果是否一致。
这跟审查别人的正则表达式很像。比如我绝不会去读一个 100 字符的正则表达式来确认它是否匹配语义化版本号，我只会把它丢进正则表达式测试器里，看看它是否按预期工作。
- econ
把公式塞进单元格里固然让人困惑，但在文件系统的某个角落放一个单次使用的脚本同样糟糕，而且看脚本也不一定能一眼看出在干什么。如果你把所有东西都塞进数据库，那你得掌握古老的 SQL 功夫。行吧，如果你会那很棒，不会那就惨了。我喜欢 join，这东西瞬间就能把没入门的人搞得晕头转向。你可以把查询写得足够复杂，连经验丰富的老手都得先热热身才能上手。
我还记得第一次看 Excel 时的想法：他们强制给每个东西都起名字和编号，这简直就像只能用单字母变量，而且只能用于简单的事情。用行号甚至更糟。每多一列数字，找东西就更难，也更容易出错。
我不是在抱怨，每种方案之所以能存活下来，是因为它们都有巨大的优势。JSON 和 XML 当然也有它们的用武之地。
我的直觉是，在了解了各自的优缺点之后，我们应该能做出更好的东西。
我把 CSV 放在 HTML 文档里，用 JS，直接从文件系统运行，输出通常是 CSV。我还没测试过 HTML 文件的极限，但如果你在底部加个注释，渲染引擎会高效地忽略它。
再送你一个糟糕的方案，丰富你的收藏。