小编Vér*_*ace的帖子

我最近发现 MySQL 有一个我不知道的“内存”引擎（我的大部分数据库工作都是针对业余项目的，所以我边走边学习我需要的东西）。似乎这个选项应该让我大大提高性能，所以我想知道它是否有任何缺点。我所知道的两个是：

1. 我需要有足够的内存来保存有问题的表。
2. 如果机器关闭，这些表就会丢失。

我相信 #1 不应该是一个问题，因为我使用的是 AWS EC2，并且可以根据需要移动到具有更多内存的实例类型。我相信我可以通过根据需要转储回磁盘来缓解 #2。

还有哪些问题？内存引擎能否提供比 MyISAM 或 InnoDB 更差的性能？我想我读过一些关于这个引擎的索引不同的东西；这是我需要担心的事情吗？

我想知道复合主键是否是不好的做法，如果不是，在哪些情况下使用它们是有益的？

我的问题是基于这篇文章

注意关于复合主键的部分：

不良做法 6：复合主键

这是一个有争议的观点，因为现在许多数据库设计人员都在谈论使用整数 ID 自动生成的字段作为主键，而不是由两个或多个字段的组合定义的复合字段。这目前被定义为“最佳实践”，就我个人而言，我倾向于同意它。

然而，这只是一个约定，当然，DBE 允许定义复合主键，许多设计人员认为这是不可避免的。因此，与冗余一样，复合主键是一种设计决策。

但是请注意，如果您的具有复合主键的表预计有数百万行，则控制复合键的索引可能会增长到 CRUD 操作性能非常下降的程度。在这种情况下，最好使用一个简单的整数 ID 主键，其索引足够紧凑并建立必要的 DBE 约束以保持唯一性。

定义有点混乱 - 基本上我在问 SQL 是否是 NoSQl 系列的子集：

我问这个是因为“不仅”意味着 NoSQL 更大，但仍将 SQL 作为其中的一部分。

另一方面，由于我们无法在 NoSQL 数据库中执行典型的 sql 操作，例如连接，因此 SQL 不是 nosql 的一部分！

我想知道哪个是真的？

我已经阅读了 JSON 对象和 JSON 对象类型。我只想做一个选择，它返回 JSON。我不一定要存储 JSON 对象。序列化本身不是我的问题。列是常规的 Varchar、Int 等列，没有 JSON 对象，“普通”数据库行。

我可以执行常规的旧 SELECT 并为 MySQL 返回 JSON 吗？

这不是SQL SERVER 中的FOR JSON和PostgreSQL 中的rows_for_json所做的吗？

他们似乎在这方面领先，但我不想欺骗自己。

我从 2016 年发现了这个问题：https : //stackoverflow.com/questions/35324795/mysql-5-7-return-row-as-json-using-new-json-features

如何从二进制文件恢复我的文件和照片？

我已经安装了 mysql 5.7，并且不时（每几天一次）它会寻找更新（据我所知）。控制台窗口打开几秒钟，然后消失。没关系，我这次正在看电影，而这个控制台在我的播放器的顶部。真的很烦人，为什么MySql 以这种用户不友好的方式更新？我可以将其配置为静默执行吗？

对此问题予以启发这一个（闭合）和几乎是相同的这一个，但使用不同的RDBMS（PostgreSQL的对比的MySQL）。

假设我有一个肿瘤列表（这个数据是根据真实数据模拟的）：

CREATE table illness (nature_of_illness VARCHAR(25), created_at DATETIME);

INSERT INTO illness VALUES ('Cervix', '2018-01-03 15:45:40');
INSERT INTO illness VALUES ('Cervix', '2018-01-03 15:45:40');
INSERT INTO illness VALUES ('Cervix', '2018-01-03 15:45:40');
INSERT INTO illness VALUES ('Cervix', '2018-01-03 15:45:40');
INSERT INTO illness VALUES ('Cervix', '2018-01-03 15:45:40');
INSERT INTO illness VALUES ('Lung',   '2018-01-03 17:50:32');
INSERT INTO illness VALUES ('Lung',   '2018-02-03 17:50:32');
INSERT INTO illness VALUES ('Lung',   '2018-02-03 17:50:32');
INSERT INTO illness VALUES ('Lung',   '2018-02-03 17:50:32');
INSERT INTO illness VALUES …

1.我们有一个 Google 的 Protocol Buffers 格式的模式定义，我们用它来为不同的 gRPC 实现（Python、PHP）生成代码

2.我们有一个数据库 (PostreSQL)，它从映射 Protocol Buffers 结构的 SQL 文件初始化。

问题： protobuf 规范经常发生变化。这必须反映在数据库中，这是一项繁琐的任务，手动完成时容易出错。

我们最近转移到 Alembic 迁移，以便在我们更新协议缓冲区规范时将持续更新迁移到（实时）数据库结构。但是，我们仍然觉得我们需要维护两个基本相同或至少非常相似的结构：ProtoBuf 和 SQL-Code（通过 Alembic Migrations 或在纯 *.sql 文件中管理）。

我一遍又一遍地搜索，关于其他人如何解决这个问题的信息很少。理想情况下，我们希望建立一个 CI/CD 流程，将 protobuf 规范（例如，消息名称从 更改teaspoon为knife）转换为 SQL 模式定义（例如CREATE TABLE teaspoon (...);）或从中创建 SQL 迁移代码（例如ALTER TABLE teaspoon RENAME TO knife;）。

我知道它实际上比我的简单示例更复杂，但我什至找不到支持半自动和人工监督转换的代码。有什么建议吗？

到目前为止我发现了什么：

• 从 SQL 文件，我们可以创建一个 PostgreSQL 数据库（例如在 Docker 中）并使用sqlacodegen自动创建一个 SQLAlchemy 模型
• 从 SQLAlchemy 模型，我们可以使用 Alembic 迁移来创建（半）自动模式迁移代码
• 我们回到零点：我们需要维护基本的 SQL 文件和 protobuf 规范
• 有 …

作为这个问题的后续行动，我有一个我自己的。

最初的问题涉及使用CASE超过 100 个选项的语句，并且该语句必须在 4 个地方使用 - 所以显然 SQL 非常多毛。OP 的问题与 SQL Server 2012 有关，但是我的问题是关于 PostgreSQL。

在我的回答中，我建议使用 aVIEW作为“一站式”解决方案 - 即声明VIEW一次，在任何地方使用它 - 这也适用于未来的任何查询及其任何变体。

另一位发帖人（@AndriyM）建议使用 aCROSS APPLY来解决该问题，这是另一种解决方案。PostgreSQL 语法是JOIN LATERAL

然后，我在原始答案中添加了 CTE（通用表表达式）作为另一种可能的解决方案。

因此，OP 现在有 5 个选项：

1. CASE
2. VIEW
3. JOIN LATERAL（CROSS APPLY对于 SQL Server）
4. CTE
5. Separate table

我排除了更改基础数据的选项，因为在本论坛中，顾问/DBA/程序员经常不允许更改基础数据 - 也使答案更有趣！

显然，CASE具有 > 100 个选项 (x4)的表达式非常麻烦和复杂 - 但什么时候使用是个好主意CASE，在什么时候它会变成减号而不是加号？

在我看来（不仅仅是因为这是我的答案！），aVIEW是最佳解决方案 …

使用 postgresql 9.6。

该表有用户会话，我需要打印不同的非重叠会话。

CREATE TABLE SESSIONS(
            id serial NOT NULL PRIMARY KEY, 
            ctn INT NOT NULL, 
            day DATE NOT NULL,
            f_time TIME(0) NOT NULL,
            l_time TIME(0) NOT  NULL
        );     
    INSERT INTO SESSIONS(id, ctn, day, f_time, l_time)
    VALUES
    (1, 707, '2019-06-18', '10:48:25', '10:56:17'),
    (2, 707, '2019-06-18', '10:48:33', '10:56:17'),
    (3, 707, '2019-06-18', '10:53:17', '11:00:49'),
    (4, 707, '2019-06-18', '10:54:31', '10:57:37'),
    (5, 707, '2019-06-18', '11:03:59', '11:10:39'),
    (6, 707, '2019-06-18', '11:04:41', '11:08:02'),
    (7, 707, '2019-06-18', '11:11:04', '11:19:39');

sql 小提琴

id  ctn day         f_time      l_time …