问题

我计划将包含更多 1000 万条记录的 CSV 加载到 PostgreSQL v12.1，其中一列具有“分类”值，因此为其创建枚举类型似乎是一个不错的选择，但它包含 208 个类别。

最短的字段为 2，最长的字段为 11 个字符。所有字段的平均值为 2.4。字符编码是 UTF8，但所有字符都是 ASCII。

问题：

我应该使用enumerated或varchar哪种类型？

附加信息

我丢弃char是因为官方 PostgreSQL 文档说明了有关char、varchar和text 的以下内容：

提示：这三种类型之间没有性能差异，除了使用空白填充类型时增加了存储空间，以及在存储到长度受限列时需要额外的一些 CPU 周期来检查长度。虽然 character(n) 在其他一些数据库系统中具有性能优势，但在 PostgreSQL 中没有这样的优势；事实上 character(n) 通常是三个中最慢的，因为它有额外的存储成本。在大多数情况下，应改用文本或字符变化。

PostgreSQL 中的枚举值在磁盘上占用4 个字节（请参阅 8.7.4. 实现细节）。考虑到这一点和使用enum类型的2.4 平均字符串长度会导致磁盘使用率略高（PostgreSQL 中的短字符串需要一个额外的字节磁盘空间）。我仍然有一种直觉，即使用 enum 是更好的选择，因为它的实现使许多针对它的操作更快。

Python 整数类型具有无限精度，因此它能够容纳 MS SQL（64 位）的 bigint 值。当传递给外部脚本时，它仍然隐式映射到 float64 python 类型。

这可能会导致大整数的严重计算错误。

那么为什么它映射到 float64 呢？

我的猜测是：

R 是通过可扩展性架构在 Python 之前添加的，它具有固定精度的整数（32 位）。所以它不能容纳 bigint。所以也许这是一个兼容性问题。

确保精确计算的最佳做法是什么？

简单但可行的想法：将 bigint 作为字符串传递，然后将它们解析为 int。

我知道它在实践中引起问题的可能性很小，但还是很高兴知道。

怎么可能有问题：

我写了一个简单的例子来演示它怎么会是一个问题：

CREATE TABLE #test (
    big_integer BIGINT
);

INSERT INTO #test 
    (big_integer)
VALUES
    (36028797018963968),
    (36028797018963968 + 1);

EXECUTE sp_execute_external_script 
    @language = N'Python',
    @input_data_1 = N'SELECT big_integer FROM #test',
    @script = N'
print(InputDataSet.dtypes)
OutputDataSet = InputDataSet
'

在 SQL Server 2019 上执行此代码将为您提供以下结果：

| | (No column name) …

问题

主要问题我们需要在MS SQL Server 2019上使用正则表达式，能力至少达到POSIX正则表达式的水平。

可能的解决方案

这个来自 stackoverflow 的问答正确地得出结论，如果您的查询必须依赖正则表达式，您应该使用 CLR。这篇 Readgate文章详细阐述了这种方法。所以我和我的一位同事提出了这个解决方案，但我的另一位同事断然表示，在这里使用 CLR 会给安全性和稳定性带来巨大风险，而使用外部脚本（Python 或 R）更安全。

这似乎是一个可疑的说法，因为CLR 中的用户代码是可以管理的，所以也许正好相反，但我没能说服我的同事。

在我绝望中写的另一个问题中，因为我被迫使用外部脚本并且仍然产生一个极快的查询。SQLpro 用户在他的评论中指出：

就安全性而言，使用 Python 或 R 可能比使用 CLR 更糟糕！

我倾向于相信。

问题

所以我有两个问题：

1. 这正则表达式的解决方案更安全的外部脚本或基于CLR（如描述这里）？为什么？

2. 我还建议在同一个 Windows Server 上运行 python 代码（必须是同一个服务器，因为策略）但在操作系统上安装了 python intrepeter。因为结果以任何一种方式导出到 CSV 文件中并存储在 SQL Server 中。那么我就可以使用 Python 的多处理模块来实现正确的性能。答案是相同的，在 SQL Server 中运行 Python 比在外部应用程序中更安全。这也是一个有问题的说法。