Donnie L 写了: ↑周一 11月 29, 2021 2:52 pm看了国外论坛关于“Primary Key Best Practice”的讨论,用序列号和UUID各有千秋吧,UUID性能的下降有些大佬提过。我想,如果数据库不是特别大,用UUID可能是更好的选择。Pros and Cons as I see them without recommending any one PK option over another:
Serial Numbers--once the only option. FileMaker's supported this option for decades.
Pro:
Implementation is very simple and easy to work with. It's easy when inspecting data to see what record was created first
Con:
Values are only unique in context of current table, current file. If you need to import data from multiple copies on multiple tables, you'll get duplicates. If you import data, say into an updated copy of the solution and fail to update the next serial value setting, you get duplicate values and a major problem with your data.
s:
Pro:
The value is unique and unique across all records and even across all tables and across multiple copies of your file. There is no chance that simply importing the data into a new copy of the file will cause duplicate values to appear.
Cons:
Slow indexing that needs "fixing" with methods such as using a CF to produce a numeric only . When working with the data directly--say to debug issues, those long strings are a bit "clumsy" to work with compared with the simple integers of an incrementing serial number.
如果记录数没超过100w,我觉得用uuid与用序号的差别不明显,超过100w的情况我也没专门测试过
默认情况下我在做开发时都是直接用uuid做主键值
关于uuid值太长看起来啰嗦的问题,可以另做一个辅助字段用来存储recordid,这个值就是序号了
国外也有开发者说数据表里不建议有过多字段,表越窄(narrow,字段少的意思)越好,
不过我目前也没觉得辅助字段的增加会对效能有啥影响呵
FYI