我是数据库的新手，下面是我的一个查询及其解释，我觉得它太复杂了。它有效，但我担心设计不好。
为购买了数据库中最赚钱的作者所写的任何内容的客户提供客户信息列表。
SELECT E.id,NAMES.fname, NAMES.lname, E.address, E.city, E.state,E.country, E.email, E.phone, E.postalcode
FROM ENTITY AS E, (SELECT DISTINCT T.customer_id
FROM (SELECT DISTINCT O.order_id
FROM ORDERITEM AS O
WHERE O.bid IN (SELECT DISTINCT A.b_id
FROM AUTHOR AS A
WHERE A.name_id IN (SELECT DISTINCT NA.name_id
FROM (SELECT A.name_id, A.b_id
FROM (AUTHOR AS A JOIN NAMES AS N ON (A.name_id = N.id))
GROUP BY A.name_id) AS NA,(SELECT B.b_id AS bid, max(C.total_quantity * B.price), B.title
FROM BOOK AS B, (SELECT bid, SUM(quantity) AS total_quantity
FROM …我正在尝试编写我的第一个大型后端项目。这是一个类似于 Instagram 的移动/网络应用程序，但用途不同。当我在互联网上搜索时，我发现 Instagram 使用 PostgreSQL 和 Cassandra 作为它的主要数据库。但我不知道它使用哪个数据库的目的/类型/部分数据？
有谁了解更多有关 Instagram 使用的数据库的信息，或者一般情况下，我可以知道如何决定哪些服务或哪种类型的数据/应用程序最好使用 SQL 或 NoSQL 数据库吗？
postgresql database-design application-design cassandra design-pattern
什么是ID 反模式，为什么/在什么情况下它被视为反模式？
id 反模式在每个表中都有一个唯一的 ID 列。为每条新记录生成 ID。为什么这是一个反模式？– 安德鲁沃尔夫 11 分钟前
假设我正在构建一个应用程序，可以在其中添加FOO的评论。通常我会有这样的东西：
表foo和表foo_comments，其中foo_comments包含id、foo_id和其他列。
目前，这是我在应用程序中使用评论的唯一方式。我确实收到了某人的留言，如果他们将来更新应用程序并且他们也想为BAR添加评论，我应该从现在开始添加一些自定义内容，即使我现在不需要它。所以有人建议我添加这样的东西
表注释（一般用途），其中包含一个type列（其中 type 可以是表示引用的表的 int：foo、bar 或其他内容）和一个type_id列，其中包含来自行的 id主表。
那么这是一个好的做法吗？我是否应该构建这样的东西，仅仅因为应用程序将来可以更改？或者我只是将其与foo_comments表一起保存，然后如果应用程序将为BAR表添加注释，我也会创建一个bar_comments表。
我正在寻找关于在不同实体之间共享的实体的特定“最佳实践”或“模式”，这些实体与众多实体中的一个有关系。
例如，可能有通用实体“地址”，它可用于存储客户、供应商、员工等的公共地址字段......
经验丰富的 DBA 会采取这种方式，还是宁愿将字段添加到相应的实体中？我也在考虑可维护性，可能（将来）会因实体而异的约束，诸如此类。
我很想得到有关该主题的任何权威或既定作品的参考。