再用 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 对应的内容, 但是感觉这样设计有点浪费磁盘空间
我现在有点迷茫, 不知道该怎么搞. 各位有什么意见没
这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。
https://www.v2ex.com/t/357415
V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。
V2EX is a community of developers, designers and creative people.