为自嵌套或单表的多对多关系设计模式的正确方法是什么
表：产品
- ID
- 姓名
- 状态
需要将产品与相关产品进行匹配/保存。
例如：产品 1 的相关产品是 3,4
产品 2 是 5,6
产品 3 是 1
产品 4 是 1
产品 5 是 2
产品 6 是 2
我创建了一个连接postgres并执行各种查询的后端 api。
我为该后端 api创建了一个特定用户（角色 + 可以登录权限）：
backend_api_user
我还放弃了公共模式，转而支持后端 api 使用的新模式：
apischema
为了避免必须为后端 api 所做的每个查询添加前缀，我更改了搜索路径，如下所示：
ALTER ROLE backend_api_user SET search_path TO apischema;
问题是我需要在后端 api 查询中为表的引用添加前缀。因此，即使从 postgres 的角度来看它看起来还不错，有些东西也不起作用：
SELECT usename, useconfig FROM pg_user WHERE usename='backend_api_user'
| 用户名 | 使用配置 |
|---|---|
| backend_api_user | {search_path=apischema} |
旁注：我正在使用 postgres 和 pgadmin4。两者都是我使用 docker desktop for mac 运行的 docker 容器。
太感谢了。
我正在尝试为组中的每个用户找到一种在数据库中创建模式的方法......
目标是自动化学校结构的创建过程。
比如说，每个班级都是一个数据库，班级中的每个学生都有一个可以使用的模式。但是我怎样才能自动为每个学生创建一个模式呢？
感谢您给我的任何指导或帮助。
我正在研究一个精简的数据库模式（在 PostgreSQL 中），比如旧的FreeBase，只是没有那么多东西。到目前为止大约有 100 张桌子，但那是在我考虑为特殊情况添加几十张之前，感觉不太对劲。让我用一个简化的例子来解释这个问题，它以一种小的方式复制了这个问题，想象一下它会变得更加复杂，一个表有几十个可选的属性/关系/关联，并且有许多像这样的不同的互连表。
我知道并广泛使用过像 MongoDB 这样的 NoSQL 文档数据库，并且在像 Neo4j 这样的图形数据库中涉足过。由于这个副项目的复杂性，它们是我宁愿避免使用的工具，而且用于部署的工具和资源与当今世界的 PostgreSQL 之类的东西不一样。
因此，为了说明这个问题，想象一个“符号”表，其中包含所有unicode符号，以及 unicode 范围之外的数千个符号（征兵、玛雅脚本、其他非脚本符号等）。基表如下所示：
table symbols {
id
unicode (optional)
preview_image_url (optional)
title
description
}
我们已经有了一些可选属性，因为有些符号没有 unicode，有些不需要预览图像（所有 unicode 都可以在浏览器中呈现，等等）。但是，让我们考虑一下我们想要存储有关...的结构化信息的其他一些“类型”符号。
首先，我们可以想到“脚本”符号，即用于书写系统的符号。很酷，我们可以在我们的表中添加可选的“script_name”属性，这还不错。但是不，什么样的脚本符号？有从右到左的文字、垂直文字、表意文字、字母文字、abjads 和 abugidas 等。一些字母文字如拉丁文字有镜像符号（如括号）或大写/小写对。一些脚本将字符与特定规则组合在一起，这些规则可以与哪些组合。有些符号纯粹是装饰性的，有些是几何的。因此，我们尝试考虑所有这些可选功能：
table symbols {
id
unicode (optional)
preview_image_url (optional)
title
description
is_logographic (optional)
is_vertical (optional)
is_rtl (optional)
is_alphabet (optional)
is_abjad (optional)
is_abugida (optional)
script_name (optional)
mirror_image_symbol_id (optional)
uppercase_symbol_id (optional)
lowercase_symbol_id (optional)
combining_class (optional)
}
不过，有些人可能会说拥有所有这些可选属性还不错，我不知道。
然后您可以继续并添加更多子子类型....
- 类似三角形的符号（在 unicode 中有一些）
- 阴影三角形符号
- 空三角形符号
想象一下你可以尝试在谷歌上搜索与符号相关的所有可能的东西。
- 看起来像“c”的符号
- ©（版权符号）
- ?（版权符号）
- ℃（摄氏度的符号）
- ¢（美元的美分符号）
- ₡（哥斯达黎加和萨尔瓦多货币冒号的符号）
- ₵（塞地符号，加纳货币）
- ₢（克鲁塞罗的符号，巴西的历史货币）
- ℄（实际上是“cl”
- 带有内置组合标记的符号，如 é。
- 1 字节的 Unicode 字形
- 2 字节 unicode 字形
- 4字节...
- ...
它开始变成这样：
table symbols {
id
unicode (optional)
preview_image_url (optional)
title
description
is_logographic (optional)
is_vertical (optional)
is_rtl (optional)
is_alphabet (optional)
is_abjad (optional)
is_abugida (optional)
script_name (optional)
mirror_image_symbol_id (optional)
uppercase_symbol_id (optional)
lowercase_symbol_id (optional)
combining_class (optional)
is_triangle_like (optional)
is_shaded_triangle_like (optional)
is_empty_triangle_like (optional)
looks_like_c (optional)
looks_like_d (optional)
looks_like_l (optional)
...
has_built_in_diacritic (optional)
is_1_byte (optional)
is_2_bytes (optional)
...
}
很快我们就会得到 50 或 100 个可选字段。当您尝试对“生物体”及其所有独特而多样的特征进行建模时，您可以想象这会变得更加复杂！数以千计的可选功能，并且没有明确的 OO 类层次结构来创建子类，它更像是一个互连组合的图/网络。
所以我的想法开始转向让事情变得超级抽象/通用，并创建一个名为“facts”的表格，比如：
table facts {
id
object_type
object_id
property_name
value_type
value_id
}
这样你就可以创建一个像“symbol a”这样的对象，并在它上面有“facts”，比如“属性名称是script_name，值类型是一个字符串表，其中一个字符串映射到一个ID，作为对象符号类型的属性” . 或者另一个事实是：
// facts table
id: 123
object_type: 'symbol'
object_id: 12321
property_name: 'is_1_byte'
value_type: 'boolean'
value_id: 444
// boolean table
id: 444
value: true
// symbol table
id: 12321
unicode: 'a'
但是沿着这条路走下去，你最终只会得到几个表（基本上是“事实”表，可能还有 1 或 2 个其他元表），而不是 100 个。但是事情变得更加难以思考和可视化，并且查询变得更复杂一些。
但我看不到解决这个问题的方法。我倾向于让数据库成为这种抽象类型的“事实”表，但是在应用程序层中让它看起来更面向对象，就像在 JavaScript 中一样，它有属性或没有属性。我想稍微“强化”一下，并给每个组合/变体一个不同的类型名称，但这并不完全奏效，例如：
{
type: 'alphabet_symbol',
value: 'e'
},
{
type: 'geometric_symbol',
value: '▲'
}
然后构建一个类型树：
symbol
alphabet_symbol
mirror_image_alphabet_symbol
mirror_image_alphabet_symbol_with_capital_lowercase
capital_lowercase_alphabet_symbol
abjad_symbol
geometric_symbol
triangle_geometric_symbol
shaded_triangle_geometric_symbol
但这打破了：
symbol
alphabet_symbol
(cyrillic б)
look_like_6_symbol
(cyrillic б)
所以就像，也许只是向中心对象添加标签。
б
id: 455
tags
- name: 'is_alphabet_symbol'
symbol_id: 455
- name: 'looks_like_6_symbol'
symbol_id: 455
但在这一点上，它归结为我最初在您开始尝试处理更多案件时分享的通用/抽象“事实”想法。
// facts table
id: 124
object_type: 'symbol'
object_id: 455
property_name: 'is_alphabet_symbol'
value_type: 'boolean'
value_id: 444
// boolean table
id: 444
value: true
// symbol table
id: 455
unicode: 'б'
所以想知道，这里简要概述的处理“类型”的动态性和变化的推荐方法是什么？您如何平衡捕获尽可能多的结构化数据的愿望而不制作一个大的可选填充平面表（这似乎在几十个可选列之后分解，更不用说在有机体建模的情况下为 100 或 1000） .
我正在使用别名登录我的 Postgres 12（在 Windows 10 上运行）数据库，该别名解析为
PGPASSWORD=$DB_PASSWORD psql -U${DB_USER} $DB_NAME
我想找到一种方法来告诉 Postgres 在登录时默认使用哪个模式，无论是在命令行还是其他方式。我尝试设置“search_path”...
> login_to_my_db
psql (12.11)
WARNING: Console code page (437) differs from Windows code page (1252)
8-bit characters might not work correctly. See psql reference
page "Notes for Windows users" for details.
Type "help" for help.
my_db_name=> show search_path;
search_path
-----------------
"$user", public
(1 row)
my_db_name=> set search_path = 'my_schema';
SET
my_db_name=> show search_path;
search_path
-------------
my_schema
(1 row)
但是一旦我注销并重新登录，搜索路径设置就消失了
my_db_name=> \q
> login_to_my_db
psql (12.11)
WARNING: Console code page (437) differs from Windows code page (1252)
8-bit characters might not work correctly. See psql reference
page "Notes for Windows users" for details.
Type "help" for help.
my_db_name=> show search_path;
search_path
-----------------
"$user", public
(1 row)
我如何保存它或至少告诉 psql 登录时使用什么模式？
我正在通过 MNE Python 读取多组科学数据（EEG 数据的欧洲数据文件文件）。每个 EDF 都可以使用包含时间基准的 Numpy 数组读取，例如 0.00、0.01、0.02、0.03... 和通道数，每个 Numpy 数组表示沿该时间基准的测量值 [-3.00, 4.40, 2.20, 3.40] 用于通道“FZ-CZ”，[1.24, 1.34, 1.00, 3.11] 用于通道“CZ-PZ”。这些频道具有在记录中唯一的文本标签，但可能因记录而异。
背景
我的非理想想法是将这些放在普通 Postgres DB 中的表中，但通道标签可能不一致，对于具有数十个通道的文件来说，这将是几分钟的很多行. 也许有一个“频道”表，我可以在其中保留所有文件的所有频道的运行列表并避免重复，但这再次违背了我的更好判断。
|PatientId|Channel|Time|Voltage|
--------------------------------
| 1| FZ-CZ |0.00|-3.00 |
| 1| FZ-CZ |0.01| 4.40 |
| ... | ... |... | ... |
| 1| CZ-PZ |0.00| 1.24 |
| 1| CZ-PZ |0.01| 1.34 |
更让我不寒而栗的是，为不同的记录提供不同的表格，其中包含可变数量的列，这些列由通道的电压值组成。
我找到了一篇关于欧洲数据文件主题的完整论文（链接直接下载 PDF），这似乎鼓励使用将这些跟踪作为二进制数据存储在表中。我不介意将此作为次要选项，但我希望能够直接查询数据。
在搜索该站点时，我发现以下 3 个问题很有帮助，并且更倾向于寻求时间序列数据库解决方案。 时间序列科学数据的设计选项
科学数据设计。具有数百列的数据表或具有通用值列和数百行 (EAV) 的数据表？
问题
从那一点研究中，我决定追求像QuestDB或Timescale甚至 Amazon Timestream 这样的东西，但似乎所有这些解决方案都面向 a.) 每个数据点都有准确的时间戳（比如“01/01/ 2022 00:00") 和 b.) 在进行测量时将数据点增量添加到表中。否则，这些解决方案似乎是存储此类数据的理想选择。
除了将我的数据的相对时间点转换为绝对时间戳之外，有没有办法让它与时间序列数据库一起使用？如果不是，我是否“卡住”了将这些数据存储为字节/blob，甚至像 JSON 这样的数据存储在表中，甚至只是将文件保存在 S3 存储桶中并根据需要读取/写入它们？
我正在努力寻找关于以下主题的更好方法，并希望得到任何建议。
一、说明：
数据库用途——仓库存储。有几个实体，例如：
- t_resource（来自产品的制造）。
- t_product（由资源制成的最终产品）。
- t_rack 存储项目的位置。
- t_item 可以是产品或资源的类型。
2.问题：
如何以适合项目的方式抽象资源和产品并在以后轻松搜索。
3. 我的想法和可能的解决方案：
- 引入名称为“type”的 t_item 表列，这将有助于区分资源和产品的 id -> 这种方法似乎有很大的缺点，特别是如果我想加入代表表以带来产品和资源的详细信息。
- 为 t_rack 存储引入独立的表并拆分为 t_rack_res 和 t_rack_product -> 当需要显示两个表中的所有项目时，此解决方案可能会遇到相同的问题。稍后如果需要缩放项目类型，我将陷入创建另一个表的问题。
- 将产品和资源合并到一张表中——我不喜欢这个想法的唯一原因是，实际上这两件事是不同的，应该分开，因为产品应该由资源制成并包含它。
我正在为客户处理的一个 sql 数据库是用一种不寻常的结构创建的。
例如，不要为以下各项设置一个表：
国家，
状态，
城市，
单位（英寸、米、英里/小时）、
他们只有两张桌子：
- 一个用于列表 ID（字段：列表索引和列表名称）。记录前：城市，单位
- 一个用于给定列表中的项目（字段：项目索引、列表项的描述和引用上述相关列表索引的 fk）。记录前：km/h、亚特兰大、英里、巴黎
listitem 表中 id 的序列是这样组织的，以便在一定程度上将 listitem 中不同组的项目分开，以防需要在列表中添加新项目：
Unit 的 Seq 可能从 20000 开始
城市序列可能从 30000 开始
因此，如果需要添加 10 个新单位，则索引可以与其他已创建的单位保持分组，而不会在其他项目（如城市）中溢出。应用层处理每组项目的序列范围。
他们在列表表中有 30 多个这样的列表，并且在项目表中有数千个项目，每个项目都与列表 ID 相关。
我认为这是没有意义的，原因有很多。但他们认为这很有效，因为“我们只有 2 张桌子而不是 30 张桌子”。他们还认为这是一种新颖且有点典型的工作方式。我知道这在技术上是可行的，但我预计这两个表的实现会出现不必要的和多重问题。
我的问题：做上述事情是典型的还是公认的做法？
我正在尝试帮助我的妻子为她的项目创建一个模式，但我对她的一些数据以及如何对其建模感到有些困惑。
她有一堆进入数据库的“标准”。这些都相当简单。就像是：
Standards
ID Code Description
-- ---- -----------
1 7DF1 Description of some standard blah
2 7DF2 Description of some other standard asdf
3 8A33 Yet another description
但是，这些“标准”中的一些有一种“不合标准”。所以 8A33 可能有 a、b 和 c 部分需要单独引用。
所以很容易创建一个如下所示的 Substandards 表：
Substandards
ID StandardID Code Description
-- ---------- ---- -----------
1 3 a Description of 8A33 part a
1 3 b Description of 8A33 part b
但是现在其他表需要参考一个标准，这个标准可以是正常的标准，也可以是不合格的。我不知道如何保持正常形式。我能想到的就是这样做，但这似乎是错误的：
SomeOtherTableThatReferencesStandards
ID StandardID SubstandardID
-- ---------- -------------
1 1
2 2
3 3 a
4 3 b
SubstandardID 字段中存在空数据表明我可能做错了什么，但我想不出更好的方法来做到这一点。我考虑过有一个字段告诉您 ID 是标准还是子标准，但是我不能真正保持参照完整性（没有外键）。
我知道这有点模糊，因为我这里没有真实数据，但我认为这可能是一个很容易解决的常见问题，我希望有人能认识到它。
我是数据仓库模式的新手，我对角色扮演维度感到困惑。我已经搜索了很多关于数据仓库中的日期的信息，它们在链接到单个日期维度的事实表中给出的关于日期（订单日期键、发货日期键、发货日期键）的示例总是相同类型.这是有道理的，但在我的架构中（我的架构更大，但只是一个例子）我有一个登录维度（日期、开始时间、结束时间、持续时间），它链接到链接到销售维度的“操作员”维度。我的架构中的 fact_sales 有日期，我假设这些日期将链接到日期维度（例如“销售日期”），但是具有登录日期的登录维度呢？我可以将它直接连接到日期尺寸还是根本不应该有连接？