@lihongjie0209 我理解你的意思是不清楚具体业务的场景下，用自增主键是一个实现细节。
但是从业务的角度来讲，是否允许依赖插入有序这个保证通常就是系统设计的基础特性而不是实现细节。如果这样的基础性质会被需求变更推翻，整个数据库设计很可能都得推倒重来。
这类数据库设计的决策本来就得在这种业务需求明确后才能做，你的测试能先于业务需求明确前搭建？考虑这类需求变更导致数据库设计的整体不确定性，你确定这样出来的测试能覆盖多少内容才能确保业务变化有更大适应性？特别地，一些业务就算不用自增主键，也得用其它逻辑来实现这个保证，你如何应对测试这些东西的需求——测试 DB 可能确实是简单了，但测试整个系统呢？

@blueberryman 可移植性是相对而言，POSIX 环境你要折腾基本上不用考虑区别，但没 POSIX 原生支持就可能有问题。像 Windows 下没直接对应管道文件的东西，Windows 的管道不共享 Win32 文件系统命名空间（一般应用没事也不会折腾 NT 命名空间），自然可移植性就差。
如果是普通的文件，直接标准 C 的 API 可能都够用——创建文件有 C11 的 'x' mode 支持下 fopen 都够了。虽然 stdio 的缓冲是多余的，但考虑应用都能容忍 shell 的性能的场景这个不是什么大问题——只不过实际情况是，就 Windows 对 C 的支持，还不如直接 open 了。当然，微软默认还不想让你用 open （没 deprecated 的是 _open ），这个另说。
实际的主要问题是，既然说白了只是想要在 VFS 里有个占位符，没需求非得用特殊文件，干嘛那么麻烦特意用管道文件？

UUID varchar，呵呵……

@passerbytiny 你搞反了扯蛋的方向。

首先，键的规模开销不是只有空间性能，之前回复的还反过来强调问题主要是响应性能开销。（之后也有别的回复提到。）
其次，对于通常的数据库，每行都有不可压缩的键的情况下，键的规模影响存储成本体现在整行数据中的占比。
注意考虑现有产品的承载能力，大数据的所谓大体现在行而不是列的规模。
存储再不值钱也不保证不要钱，扩大键的存储占用，越大数据绝对成本增加得越大，反而你不怎么大数据倒不用计较那么多。

定性都不正确，你还是不要纠结是不是得抛开具体数字的问题了。

另外真要杠你就该说零概率都不表示不可能事件，所谓的“没有概率”是什么鬼？

@lihongjie0209 要不要自增主键本来就和业务相关。前面有说业务内容了？

福报了，改换为任意极低重心姿势。

@jaskle 超市免费领纸巾可不会有机会要收货地址和收件人信息。

不要甩锅给百度，这里就是华为的产品屎了。官方版本好用 100 倍。
至于可信性问题，不自己撸的输入法原则上没法解决——就是给你坨输入法代码你都看不完。另外，新的 EMUI 输入敏感信息应该可以调用出安全键盘而不用自己装的输入法——要是觉得菊花不可信就别用它家的设备了。

所谓的设计模式就是因为解决的问题（如果有的话）过于局部而没资格作为架构模式复用又没法作为惯用法的鸡肋。

跟很多初学者想象的相反，绝大多数所谓的设计模式跟设计没什么直接的关系，而更接近要成为惯用法却因为语言设计的局限性（例如缺乏一等函数）而失败的半吊子，因此实际上也没用于解决什么设计上的问题，反倒因为模糊问题领域而造成误导。
只有少数周知的设计模式是例外，例如 MVC 可以认为是半个架构模式。剩下的设计模式只能认为是解决了设计的某些表达困难这种实现上的问题。
典型地，一些所谓的创建型模式，就是因为创建对象的语言特性过于特殊（构造器是函数却具有普通的函数以外的特殊规则），根本不方便复用而发明的变通。例如，C++17 引入 deduction guide 以后，所谓的 make_xxx 这样的模板方法就没多大实用性了。（虽然 deduction guide 自身有混淆 higher-order type 堵死类型系统可扩展性和无法抽象复用 helper function 的更严重的问题。）

设计模式受制于范型(paradigm) 。大多数设计模式都只适用于支持面向对象设计的语言。相比，架构模式通常不依赖范型，而惯用法则同时依赖泛型和语言。
注意，偏向于架构模式还是惯用法并不蕴含解决更多或更少的设计方面的问题，只是表达和具体语言依赖的紧密程度的差异。RAII 作为惯用法，解决的问题比大多数设计模式要“设计”得多。

虽然设计模式通常不依赖个别的具体语言，但因为范型的影响，可能受制于一类语言的设计。有些设计模式可能一开始就是语言的设计者灌输的并且强烈依赖语言特性提供可用性，例如所谓纯函数式语言常见的单子(monad) 模式，配合语法糖作为可模拟顺序求值作为惯用法。

至于所谓的的 UML 是给建模用的，表达的本来倒的确是设计，然而因为历史原因方法论上非常有局限性，基本只能面向对象，不能适应其它范型的实现。
UML 跟各种意义的模式本来就没什么关系，只是一开始搞的设计模式都是面向对象的模式，才恰巧能用得上。
用到了 UML 表达的模式和使用代码表达模式的例子相比看上去是提升了抽象层次，实际只是强烈暗示看起来不像是平凡的惯用法而已，结果反而容易弱化模式的外延而显得不准确（例如，误认为创建型模式一定需要用到类）。这是因为根本上 UML 的表达能力还不如通常的编程语言。
因此，照着 UML 这样弱的语言去套用模式，基本上是不理解模式的。

不少设计模式的发明者本身不理解他们所使用模式的名称的内涵。例如，提出解释器模式的，看上去就根本没写过一个 REPL，以至于抓不住解释器提供的是面向 IR （排除包括语法在内的任何典型的文法分析）的翻译而不是对所谓的“表达式”求值（包含语法分析）的核心本质。
考虑到很多设计模式除了名字以外就没什么值得记忆的地方（例如你会用 singleton 还不如搞清楚和 monostate 的区别），设计模式中有用的部分，就是拿来即兴发明而不是取名的。照着具体组成的名字骑驴找马，不仅本质上是反模式的学习方式，可以说还是“反方法论”的。

（看起来 v2 也得像贴吧一样加个 FAQ 清单么……）

SB2，烫烫烫，，，
（虽然平时不太会烫到手。）

下载新版程序从来就没灵验过，求破。

@lc1450 凡是会大量创建 memory mapping 的程序 1809 开始就莫名其妙各种 segfault 了，不重启不会好还可能过会蓝屏，每次都回退 1803 才解决，估计是内核缓存子系统有坑。1903 只是推迟了抽风的时间几分钟到几小时不等。反正官方都没说 SB2 支持就不升了。

@litmxs 组策略还干不掉？

@onionKnight888 赛百味就算了，几年前瞎点了￥ 350 也就管饱一天多点……这坨换 KFC 能顶 72h。

就那么容易用→就没那么容易用……

看起来不是 flock，是 /var/lib/pacman/db.lck 之类的吧……实现容易，可移植性（跨操作系统、体系结构和语言）好，外部可见可查询状态允许多实例共享，程序中途挂掉状态维护失败留下烂摊子时在用户界面就能干掉，必要时可以方便附加元数据（文件属性和内容）。
管道和 FIFO 之类比普通文件可移植性差。至少 Windows 上就那么容易用。