主键创建方式选择

[Donnie L]

FM提供了很多主键的创建方法，学习FTS12时，其中写到：

使用Get（UUD）作为主键使用自动输入的序列号是创建主键的好方法， FileMaker Pro12中提供了另一种方法，即Get（UUID）函数。（您会在第5章中了解到有关函数的更多信息。）该函数会生成通用唯一标识符（UID），即个16字节的英数字符串，如“C1507CEAE3C1-425DBA86CE04FA4EEE6.此D在您可能使用的另一个表或文件中极不可能重复。因此，如果您开发的解决方案需要一组用户离线创建记录然后再将这些新记录同步处理回服务器，那么这个特别有用。（在这种情况下，序列号键就不那么有效了两个离线用户很容易就可能分别创建了具有相同主键的新记录，导致记录在被推送回服务器时发生数据问题。）这种计算以及结果字符串会增加文件的复杂性和大小，如果您没有预料到上述那样的问题，请不要考虑对键字段使用序列值。

另外，FM 17以后，提供了Get（UUIDNumber）来创建数值型序列号【24字节（192位）】，曾经看过一篇文章说，Get（UUID）生成字符串，索引非常大，会带来高昂的维护成本，推荐选择Get（UUIDNumber）创建数值型。

而另一方面，从FM17开始，每个新表都会创建默认字段，主键字段自动选择Get（UUID）来创建。

请教各位大佬，如果不考虑离线创建记录，就不需要运用Get（UUID）来创建记录了吗，Get(UUID )或则Get（UUIDNumber）会对性能带来什么样的影响。

[bigstar]

已经用get(uuid）生成主键这种方式很多年了，迄今为止没有发现这会对性能有啥影响

[Donnie L]

看了国外论坛关于“Primary Key Best Practice”的讨论，

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.

用序列号和UUID各有千秋吧，UUID性能的下降有些大佬提过。我想，如果数据库不是特别大，用UUID可能是更好的选择。

[bigstar]

看了国外论坛关于“Primary Key Best Practice”的讨论，

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.

用序列号和UUID各有千秋吧，UUID性能的下降有些大佬提过。我想，如果数据库不是特别大，用UUID可能是更好的选择。

如果记录数没超过100w，我觉得用uuid与用序号的差别不明显，超过100w的情况我也没专门测试过
默认情况下我在做开发时都是直接用uuid做主键值
关于uuid值太长看起来啰嗦的问题，可以另做一个辅助字段用来存储recordid，这个值就是序号了
国外也有开发者说数据表里不建议有过多字段，表越窄（narrow，字段少的意思）越好，
不过我目前也没觉得辅助字段的增加会对效能有啥影响呵
FYI

[Donnie L]

辅助字段，就是再UUID外，另外创建一个序列号（serial number）吗

[bigstar]

对