SQL Server中数组数据类型的任何替代方法

PostgreSQL允许将表的列定义为可变长度多维数组。像这样：

CREATE TABLE sal_emp 
(
    name            text,
    pay_by_quarter  integer[],
    schedule        text[][]
);

一些INSERT语句如下所示

INSERT INTO sal_emp
VALUES ('Bill', '{10000, 10000, 10000, 10000}',
        '{{"meeting", "lunch"}, {"training", "presentation"}}');

INSERT INTO sal_emp
VALUES ('Carol', '{20000, 25000, 25000, 25000}',
        '{{"breakfast", "consulting"}, {"meeting", "lunch"}}');

SELECT * FROM sal_emp;

输出：

 name  |      pay_by_quarter       |                 schedule
-------+---------------------------+-------------------------------------------
 Bill  | {10000,10000,10000,10000} | {{meeting,lunch},{training,presentation}}
 Carol | {20000,25000,25000,25000} | {{breakfast,consulting},{meeting,lunch}}
(2 rows)

---

我们如何在SQL Server或其任何替代品中实现相同的功能？

在SQL Server中没有数组数据类型的替代品。

在MS SQL中没有等效的替代品。在最新版本中只有JSON。@ IVANSTALSTON……和XML（因为SQL Server 2005）：- MuaMMMAD，即使这可能得到支持，我也会认为这是一个糟糕的设计。此类依赖列表应位于

1:n

相关的副表中。。。这个概念有一种懒散的味道：-）@Shnugo：它不一定是一个糟糕的设计（而且它在Postgres中经常被误用），如果实体的单个属性本质上是数组，那么数组就是一个不错的选择。但在这种情况下，一对多的关系将是一个更好的选择——即使在美国也是如此Postgres@Shnugo在Postgres中，这不是通过“侧桌”完成的。它是单一的、可压缩的可变长度数据结构。如果您总是读取和写入整个数组（用于应用程序中的进一步处理），但从不需要从SQL中访问单个元素，那么任何属性都可能是这种情况的候选属性（但同样：所示示例不是一个好选择的有效示例。我完全同意所示信息不应存储在数组中，甚至不应存储在Postgres中）