S-Man's questions

我面临一个问题。我必须设计一个数据库模式表结构。通常，我有一个具有一对多关系的小型分层树结构：

A 
|-B1
|  |-C1
|  |-C2
|
|-B2
   |-C3
   |-C4

现在，从我的角度来看，我有两个选择来设计这个：

1. 对于 A 和 B，我可以创建两个表，而直接通过外键table_a引用。table_a我认为，这可能是更好的方法，因为您将需要更少的查询连接操作。

   CREATE TABLE table_a (
       id int PRIMARY KEY,
       some_specific_data text
   );
   
   CREATE TABLE table_b (
       id int PRIMARY KEY,
       some_other_specific_data text,
       id_parent int REFERENCES table_a(id)
   );
   

2. 对于 A 和 BI 可以创建两个独立的表和一个连接两个表的附加关系表（就像我对多对多关系所做的那样）。在这里，两个表都更加独立，我认为这通常是可取的。

   CREATE TABLE table_a (
       id int PRIMARY KEY,
       some_specific_data text
   );
   
   CREATE TABLE table_b (
       id int PRIMARY KEY,
       some_other_specific_data text
   );
   
   CREATE TABLE a_to_b (
       id int PRIMARY KEY,
       id_a int REFERENCES table_a(id),
       id_b int REFERENCES table_b(id)
   );
   

在我看来，两者都是有效的设计。但是，我无法决定应该选择哪一个。选择选项 1 或选项 2 甚至第三个选项是否有任何论据？

编辑：

更加具体：

A 和 B 不是同一类型。你可以把它想象成：

• A是房子
• B是门
• 所以，房子有很多门
• 一扇门被一所房子所包含

我尝试使用该函数将日期字符串（年、周、星期几 = 'YYYY-WW-D'）转换为日期to_date()。

我得到了这些结果（demo:db<>fiddle）：

date string |  to_date()
-------------------------
'2019-1-1'  |  2019-01-01
'2019-1-2'  |  2019-01-01
'2019-1-3'  |  2019-01-01
'2019-1-4'  |  2019-01-01
'2019-1-5'  |  2019-01-01
'2019-1-6'  |  2019-01-01
'2019-1-7'  |  2019-01-01

'2019-2-1'  |  2019-01-08
'2019-2-2'  |  2019-01-08

我不清楚为什么一周中的每一天都会出现相同的日期。

如果我改用 ISO 格式 ( 'IYYY-IW-ID') 这会按预期工作 ( demo:db<>fiddle )：

date string |  to_date()
-------------------------
'2019-1-1'  |  2018-12-31
'2019-1-2'  |  2019-01-01
'2019-1-3'  |  2019-01-02
'2019-1-4'  |  2019-01-03
'2019-1-5'  |  2019-01-04
'2019-1-6'  |  2019-01-05
'2019-1-7'  |  2019-01-06

'2019-2-1'  |  2019-01-07
'2019-2-2'  |  2019-01-08

为什么它适用于 ISO 模式，而不适用于标准模式？我在这里错过了什么？

我经常使用这样的构造：

SELECT *
FROM
    my_table,
    my_srf(my_column)

例如这里：

CREATE TABLE my_table (
    my_col text[]
);

INSERT INTO my_table VALUES
('{a,b}'),
('{c,d,e}');

SELECT
    *
FROM
    my_table,
    unnest(my_col);

结果如预期：

my_col    unnest
{a,b}     a
{a,b}     b
{c,d,e}   c
{c,d,e}   d
{c,d,e}   e

演示：db<>小提琴

现在我稍微考虑了这个结构并感到困惑。逗号符号是 as 的快捷方式CROSS JOIN。事实上，这也有效：

SELECT
    *
FROM
    my_table
CROSS JOIN
    unnest(my_col)

但是因为这是一个交叉连接，所以这个结果对我来说看起来更合乎逻辑：

my_col    unnest
{a,b}     a
{a,b}     b
{a,b}     c
{a,b}     d
{a,b}     e
{c,d,e}   a
{c,d,e}   b
{c,d,e}   c
{c,d,e}   d
{c,d,e}   e

交叉连接将一个部分的所有记录与另一部分的所有记录连接起来。

尽管我如上所述使用此 SRF 连接，但我现在不再确定它为什么会详细工作。所以，我认为到目前为止我显然不了解 SRF 的完整功能。

因为文档让我不太清楚，所以我想请你解释一下这种行为。

我正在尝试为查询的各个部分找到正确的描述：

1. SELECT和之间的部分叫什么名字FROM？如果我只有一些列，那么我会称之为“列标识符”。但是，如果有任何函数或子查询，这会多得多。“SELECT 子句”是一个有效的描述吗？
2. 这FROM部分也是一样的。如果我只有一张桌子，我会简单地称它为“桌子”。但是如果有一个更复杂的结构可能使用连接等，那么正确的命名是什么？

为了让我的问题更清楚：

在 Postgres 中，我可以使用 JSON 函数，例如json_array_elements在两个部分中：

SELECT
    json_array_elements(my_json_column)
FROM
    my_table

或者这样做

SELECT
    elem.*
FROM
    my_table,
    json_array_elements(my_json_column) AS elem

如果我必须告诉某人此功能可以在SELECT子句中使用或作为子句的一部分，FROM哪些术语更常规？