最新

好的，请提供您需要翻译的英文内容。

曾经，我们把大量的业务逻辑卸载到数据库服务器上。嗯，当时它几乎是唯一“在线”的服务器，所以感觉这么做也没什么问题。 于是，我们在数据库服务器上堆积了大量的业务逻辑。触发器、存储过程，你能想到的，我们都用上了。然后我们才意识到，存在于数据库服务器中的代码极其难以维护——或者微软决定放弃“SQL Server是所有东西的归宿”的策略。不太确定，有点模糊了。 但是，我们仍然会以约束的形式将一些逻辑卸载到数据库中，最常见的就是外键约束。 在 15 年以上的专业编程生涯中，我不记得数据库约束保护过我参与的任何一个系统。几乎 99% 的情况下，数据库约束都是在我更改本地环境时出现的，而剩下的 1% 是在紧急情况下，我不得不对生产数据库进行紧急更改的时候。我从未见过任何日志行表明数据库约束是一种有用的保护措施。 然后是 NoSQL 世界，显然，没有这些约束，生活照样继续，而且没有人试图将外键约束移植到 NoSQL 中。 我觉得数据库约束是早已逝去的时代的遗物，而需要数据库约束的需求早已消失。 你同意吗？还是我疯了？

嗨，Hacker News！ 经过多年观察初创公司在企业级数据工具上挣扎，我们正在构建一些与众不同的东西。<p> 简而言之：自然语言 → 生产数据管道。 基于 Arrow、WebAssembly 和 CRDT 构建，实现实时协作。 但关键在于：一个产品经理可以输入“分析用户群体留存率”，就能得到一个可用的数据管道。无需 DAG，无需 YAML，不再痛苦。<p> 欢迎回答技术问题。是的，它处理背压。是的，具有 exactly-once 语义。是的，在需要时可以下沉到代码层面。 你因为太麻烦而搁置了哪些数据管道的构建？

我正在考虑购买一家盈利的非科技公司。你们有人这么做过吗？体验如何？有什么需要注意的吗？ 背景：首次购入者，职业是软件工程师。很可能使用 SBA 贷款融资。