标签: application-design

概念性问题：单个查询是否比连接更快，或者：我应该尝试将客户端所需的所有信息都压缩到一个SELECT 语句中，还是只使用看起来方便的尽可能多的信息？

TL;DR：如果我的联合查询比运行单个查询花费的时间更长，这是我的错还是可以预料的？

首先，我不是很精通数据库，所以可能只是我，但我注意到当我必须从多个表中获取信息时，通过对单个表的多个查询来获取这些信息“通常”更快（也许包含一个简单的内部连接）并在客户端将数据拼凑在一起，以尝试编写一个（复杂的）连接查询，我可以在一个查询中获取所有数据。

我试图把一个非常简单的例子放在一起：

SQL小提琴

架构设置：

CREATE TABLE MASTER 
( ID INT NOT NULL
, NAME VARCHAR2(42 CHAR) NOT NULL
, CONSTRAINT PK_MASTER PRIMARY KEY (ID)
);

CREATE TABLE DATA
( ID INT NOT NULL
, MASTER_ID INT NOT NULL
, VALUE NUMBER
, CONSTRAINT PK_DATA PRIMARY KEY (ID)
, CONSTRAINT FK_DATA_MASTER FOREIGN KEY (MASTER_ID) REFERENCES MASTER (ID)
);

INSERT INTO MASTER values (1, 'One');
INSERT INTO MASTER values (2, 'Two');
INSERT …

我正在做一个项目，我需要每天在一张表中更改大约 36K 条记录。我想知道什么会表现得更好：

1. 删除行并插入新行，或
2. 更新已经存在的行

对我来说，删除所有行并插入新行会更容易，但如果这会使表和索引碎片化并影响性能，那么我更愿意在可能的情况下进行更新并仅在必要时删除/插入。

这将是一项夜间服务，我不希望提高流程本身的速度。我更关心对这个表的查询性能，我已经有 8900 万条记录，以及这个每晚的过程将如何影响它。

对于这个夜间流程，我应该删除/插入记录还是应该更新现有记录（在可能的情况下）？

我正在处理的应用程序的核心功能似乎只是关联实体。因此，一对多关系会产生“元数据”，这些“元数据”只会为我们的应用程序功能提供（以一种或另一种方式）关联实体。

现在我们有一个实体关系图 (ERD)，它有很多一对多（超过 10 个表）和只有一个关联实体。它对该模型或应用程序有何看法？

是否可以改进，即，如果改进 ERD 以添加更多关联实体，应用程序是否可以绕过更多功能？

关联实体很少是否意味着应用程序的功能不会很丰富？

其他注意事项

我想知道的是：如果项目范围说明书导致 ERD 只有一个多对多关系和十几个一对多关系，那么这是否意味着该项目没有解决很多问题（功能）除了只数字化大量数据？

我认为，如果多对多较少，它们一开始只会镜像（除非我们为其他目的创建连接查询......）。

或者简单地说：大量的多对多关联是否意味着软件的功能将比少对多的软件更丰富（不要在这个想法中包括连接查询）？

我听说过关于生活在数据库触发器中的小鬼的各种恐怖故事，而且——更糟糕的是——系统因添加触发器而导致一连串级联事件而崩溃。

我正在考虑实施关于使用数据库触发器的严格政策。对于关注点分离，最初的想法是说：

“数据库触发器应仅用于捕获和维护审计跟踪的目的。”

• 有人有类似的政策吗？
• 是否有任何强有力的论据反对这种政策？

假设我有一个用于博客文章posts、 和架构的表

id
author
title
content

每个都post可以属于一些categories

id
name
descrtiption

所以一篇博文可以属于多个类别。

显然titleand contentin posts、 andname和descriptionincategories可以翻译成不同的语言。

那么，考虑到现有的 db 模式设计，扩展对多语言应用程序的支持的最有效和最合理的方法是什么？

我和我的同事正在讨论数据库中描述性特征的规范化，例如“状态”或“类型”。让我们将讨论的中心表称为“订单”。

在我的常规设计方法中，我会定义另一个表“OrderStatus”来描述订单的状态，然后在“Order”表上创建一个具有关系的外键，即“OrderStatusID”。

这会给我参考完整性。我可以随时加入状态，并且我的可能值始终存在于“OrderStatus”表中。

我的同事不喜欢这种标准化程度，因此他将在“Order”表上定义一个 varchar 字段“OrderStatus”。该字段将直接包含值。

status 的可能值在他的应用程序中定义，更具体地说，在 OrderStatuses 的枚举中定义，因此，除非我可以访问所述应用程序的源代码，否则我无法使用。

我习惯于将数据库的整个上下文作为关系和表存在于数据库中，并且不得不编写“WHERE OrderStatus = 'Sold'”而不是“WHERE OrderStatusID = 3”让我感到烦恼。

怎么想？我正在寻找两种方法的优点和缺点，但我主要关注性能和可读性/可维护性。

我做了一些研究，最后得出了这个结论：

数据库实例 = 进程 + 内存

数据库 =（物理）日志文件 + 控制文件 + 数据文件。

1. 这种理解是否正确？
2. 一个应用程序可以使用同一个数据库的多个数据库实例吗？
3. 数据库中的一个表可以同时被多个数据库实例使用吗？

谢谢。

我正在尝试编写我的第一个大型后端项目。这是一个类似于 Instagram 的移动/网络应用程序，但用途不同。当我在互联网上搜索时，我发现 Instagram 使用 PostgreSQL 和 Cassandra 作为它的主要数据库。但我不知道它使用哪个数据库的目的/类型/部分数据？

有谁了解更多有关 Instagram 使用的数据库的信息，或者一般情况下，我可以知道如何决定哪些服务或哪种类型的数据/应用程序最好使用 SQL 或 NoSQL 数据库吗？

假设我正在构建一个应用程序，可以在其中添加FOO的评论。通常我会有这样的东西：

表foo和表foo_comments，其中foo_comments包含id、foo_id和其他列。

目前，这是我在应用程序中使用评论的唯一方式。我确实收到了某人的留言，如果他们将来更新应用程序并且他们也想为BAR添加评论，我应该从现在开始添加一些自定义内容，即使我现在不需要它。所以有人建议我添加这样的东西

表注释（一般用途），其中包含一个type列（其中 type 可以是表示引用的表的 int：foo、bar 或其他内容）和一个type_id列，其中包含来自行的 id主表。

那么这是一个好的做法吗？我是否应该构建这样的东西，仅仅因为应用程序将来可以更改？或者我只是将其与foo_comments表一起保存，然后如果应用程序将为BAR表添加注释，我也会创建一个bar_comments表。

如果我想用一个术语来指代度量/指标和维度，什么是行业公认的好的表达方式？

指标也常用于 UI 中，例如Google Analytics或Tableau。

我的问题的上下文是针对 UI 的。如果存在，我想对它们进行分组，并使用行业公认的名称来引用它们。