Question

请原谅我的无知。我确定这是一个常见问题解答，但我不太了解这个术语，不知道该找什么。

我的公司在领土方面使用以下结构（示例如下）：

  Customer -> Market -> Area -> District -> Region
  XYZ Co. -> Queens -> NYC -> Mid Atlantic -> Northeast

每个客户只有一个市场。每个市场只有一个区，依此类推。（我不确定你是否称之为一对多或多对一。我不想错误地标记它。）

这就是我现在设置的方式：

create table region(
id           int  not null primary key,
name         varchar(24)
);

create table district(
id           int  not null primary key,
name         varchar(24),
region_id    int  references region(id) on update cascade
);

create table area(
id           int  not null primary key,
name         varchar(24),
district_id  int  references district(id) on update cascade
);

create table market(
id           int  not null primary key,
name         varchar(24),
area_id      int  references area(id) on update cascade
);
create table customer(
id         int  not null primary key,
name       varchar(32),
sixweekavg numeric, 
market_id  int  references market(id) on update cascade
);

现在我有机会改进这种设置，因为我或多或少地重写了网站。我看了这个热门页面： What are the options for storing hierarchical data in a relational database? 而且我确信我最好的情况就在那里，但我不太了解哪一个。

它是一个报告网站，因此读取的次数多于写入次数。我的一些页面显示了每个级别的聚合数据，客户到区域（以及顶部）。所以现在在一个显示地区级数据的页面上我会写一些类似的东西：

select d.name, sum(sixweekavg) as avg from customer c
  inner join market m on m.id = c.market_id
  inner join area a on a.id = m.area_id
  inner join district d on d.id = a.district_id
  group by d.name order by d.name;

非常标准的东西，对吗？我确信可以就物化视图进行完全独立的对话，但是现在我想探索一种更好的选择来构建层次结构（如果这甚至是正确的术语）。

所以给出以下摘要

PostgreSQL（可以假设这不会改变）
固定的层次结构（我的雇主可能会在某个时候添加或删除一个层，但是客户表中的每一行都将具有相同数量的＆＃34;父母＆＃34;）
显着多于写入

是否有一种方法可能比其他方法更好地进行设置？

ltree

我确实看过ltree，但我不太确定这是怎么回事。例如，在用户可以选择区域的页面上，我在区域表中查询每个区域的名称。我有一个想法是在我的customers表中添加一个ltree列来保存层次结构，但仍然维护其他表。这是一种可行而合理的方法吗？我已经搜索了ltree的真实例子，但是我发现它很短 - 我找到的大多数是为随机数量的父/子节点设计的，比如一个线程评论部分。

感谢您的帮助和耐心！

PostgreSQL层次结构（？）结构

0 个答案: