数据库和 web api 设计的问题

[wanganjun]

再用 PostgreSQL.

第一种设计:

假设有以下几个表
users (
user_id int
)
table_a (
a_id int,
user_id int // 引用 users 表的 user_id 字段
)
table_b (
b_id int,
a_id int // 引用 table_a 表的 a_id 字段
)
table_c (
c_id int,
b_id int // 引用 table_b 表的 b_id 字段
)

假设有一个 web api
(GET) http://www.example.com/c?c_id=0&b_id=0&a_id=0
实现上好像需要先检查 a_id, b_id. 需要多次 IO 才能查出 c_id 对应的内容

如果这个 api 设计成
(GET) http://www.example.com/c?c_id=0
然后用 c_id 反查 b_id, 在用 b_id 反查 a_id, 在用 a_id 反查 user_id, 最后比对 user_id 和发起请求的用户的 user_id. 感觉在实现上没多少差别


第二种设计:

假设有以下几个表
users (
user_id int
)
table_a (
a_id int,
user_id int // 引用 users 表的 user_id 字段
)
table_b (
b_id int,
a_id int // 引用 table_a 表的 a_id 字段
user_id int // 引用 users 表的 user_id 字段
)
table_c (
c_id int,
a_id int // 引用 table_a 表的 a_id 字段
b_id int // 引用 table_b 表的 b_id 字段
user_id int // 引用 users 表的 user_id 字段
)

假设有一个 web api
(GET) http://www.example.com/c?c_id=0&b_id=0&a_id=0
实现上只需要一次 IO 就能查出 c_id 对应的内容, 但是感觉这样设计有点浪费磁盘空间








我现在有点迷茫, 不知道该怎么搞. 各位有什么意见没

[srx1982]

没贴全吧

[wanganjun]

@srx1982 本来想预览的, 手抖点成了发布. 现在已经搞好了

[debye]

你这个不是 api 的设计问题，而是数据库的设计问题
然后不了解你的整体实际项目情况，所以也不好回答，简单的回答是第二个数据库设计合理一些

[minotaur]

一般来说磁盘空间不是阻碍数据冗余的原因（毕竟不会冗余存储大对象），一致性才是决定表是否要冗余字段的关键。如果不是存在一致性的问题，那么一般是鼓励冗余的。

[vjnjc]

同 3l ，信息不全无法给意见。
然而你给出的信息都倾向于用第二种，所以给出的意见也是第二种比较好。。。

[fangchang]

你有 user, a, b, c 四张表。
关系是 user has_many a, a has_many b, b has_many c 。 你可以看到 c 的数量是成倍增长的。如果你要用第二种的话，大量数据重复， 这点我个人不是很喜欢。你真要经常从子表返回父数据的话，你不如用图型数据库。 graph database 。不过在效率上，我没试过和关系型数据库的做这种类型的大量测试。 你可以自己试试。