问题列表 - 第3页

通用表表达式 (CTE) 和临时表有什么区别？我什么时候应该使用一个？

CTE

WITH cte (Column1, Column2, Column3)
AS
(
    SELECT Column1, Column2, Column3
    FROM SomeTable
)

SELECT * FROM cte

临时表

SELECT Column1, Column2, Column3
INTO #tmpTable
FROM SomeTable

SELECT * FROM #tmpTable

我是 Postgres 的新手，正在尝试迁移我们的 MySQL 数据库。在 MySQL 中，我可以向低特权用户授予SELECT、UPDATE、INSERT和DELETE特权，并使这些授权适用于指定数据库中的所有表。我一定在 Postgres 中遗漏了一些东西，因为看起来我必须一次为每个表授予这些权限。有许多数据库，每个数据库有数百个表，这似乎是一项艰巨的任务，只是为了起步。此外，一旦数据库开始运行，添加表的频率就足够高了，除非绝对必要，否则我不想每次都授予权限。

这是如何最好地完成的？

我需要从 PostgreSQL 数据库集群中删除一个数据库。即使有活动连接，我该怎么做？我需要一个-force标志，它将删除所有连接，然后删除数据库。

我该如何实施？

我dropdb目前正在使用，但其他工具也是可能的。

有关如何处理此错误的任何建议：

TITLE: Microsoft SQL Server 2017 Setup
------------------------------

The following error has occurred:

VS Shell installation has failed with exit code 1638.

For help, click: https://go.microsoft.com/fwlink?LinkID=20476&ProdName=Microsoft%20SQL%20Server&EvtSrc=setup.rll&EvtID=50000&ProdVer=14.0.1000.169&EvtType=0x5B39C8B9%25401434%25403

------------------------------
BUTTONS:

OK
------------------------------

这是一台正在运行的新笔记本电脑

• SQL Server 2016 Express
• 视觉工作室 2017
• SSMS 2017

我尝试卸载与 SQL Server 或 Visual Studio 相关的任何内容。

日志：[3500:3970][2017-11-03T16:25:20]e000：错误 0x80070666：安装较新版本时无法安装产品。

Detailed results:
  Feature:                       Full-Text and Semantic Extractions for Search
  Status:                        Failed
  Reason for failure:            An error occurred for a dependency of the feature causing the setup process for the feature to fail. …

是否应该授予开发人员查询（SELECT/只读）生产数据库的权限？我之前工作的地方，开发团队有这个db_datareader角色；我现在工作的地方开发团队甚至无法连接到生产实例。

其中一个测试实例是每周一次从生产备份中恢复的生产副本，因此开发人员实际查看数据没有任何问题。

不允许开发人员查询生产（除了根本不希望他们有权读取敏感数据）有什么好的理由？

我忘记了上次是如何启动 PostgreSQL 的（那是几个月前），我不记得数据目录位于何处。该postgres命令似乎需要数据目录的位置。

如果有帮助，我在 MacOsX 上。

/usr/local/postgres 在我的 Mac 上不存在。

使用下面提供的答案，我发现它在这里：

/usr/local/var/postgres

如何将 MySQL 表从一台物理服务器移动到另一台物理服务器？

例如这个确切的场景： 我有一个使用 innodb 表的 MySQL 服务器，大小约为 20GB。

我想将其移至新服务器，最有效的方法是什么？

存储与数据库中数据相关的二进制文件的最佳位置是什么？你应该：

1. 使用 blob 存储在数据库中
2. 使用数据库中的链接存储在文件系统上
3. 存储在文件系统中但重命名为内容的散列并将散列存储在数据库中
4. 我没有想到的东西

(1) 的优点是（除其他外）事务的原子性得以保留。代价是您可能会显着增加存储（和相关的流/备份）要求

(3) 的目标是在某种程度上保留原子性 - 如果您可以强制您正在写入的文件系统不允许更改或删除文件，并且始终具有正确的哈希作为文件名。这个想法是在允许引用哈希的插入/更新之前将文件写入文件系统 - 如果此事务在文件系统写入之后但在数据库 DML 之前失败，那很好，因为文件系统“假装”是所有的存储库可能的文件和哈希值 - 是否有一些文件没有被指向并不重要（如果你小心的话，你可以定期清理它们）

编辑：

看起来一些 RDBMS 以各自的方式涵盖了这一点 - 我很想知道其他人是如何做到的 - 特别是在 postgres 的解决方案中

\c <database_name>在 PostgreSQL 中使用将连接到指定的数据库。

如何确定当前数据库的名称？

进入：

my_db> current_database();

产生：

ERROR:  syntax error at or near "current_database"
LINE 1: current_database();

我已经看到一些专用的 MySQL 服务器，它们只使用一个内核。我比 MySQL 的 DBA 更擅长开发，所以需要一些帮助

设置

服务器非常庞大，具有 OLAP/DataWarehouse (DW) 类型的负载：

• 主要：96GB RAM，8 核 + 单个 RAID 10 阵列
• 测试：32GB RAM，4核
• 最大的 DB 是 540 GB，总共大约 1.1TB，主要是 InnoDB 表
• Solaris 10 Intel-64
• MySQL 5.5.x

注意：最大的 DB 是从 OLTP DR 服务器复制的 DB，DW 就是从这里加载的。它不是完整的 DW：仅持续 6 个月到 6 周，因此它比 OLTP DB 小。

对测试服务器的观察

• 3 个独立的连接
• 每个都有一个并发的（和不同的） ALTER TABLE...DROP KEY...ADD INDEX
• 这 3 个表有 2.5、3.8 和 450 万行
• CPU 使用率上升到 25%（一个核心被最大化）并且不会更高
• 3 次 ALTER 需要 12-25 分钟（最小的一次需要 4.5 分钟）

问题

1. 需要什么设置或补丁才能允许使用多个内核？
   也就是说，为什么 …