小编MDC*_*CCL的帖子

在相关的业务背景，既成员和组织需要有一个帐户的资金。资金可以转移

• 从会员到会员，
• 从会员到组织，
• 从组织到组织，以及
• 从组织到成员。

注意事项

为了为这种场景构建数据库，我创建了以下三个表：

CREATE TABLE Members ( 
  memberid serial primary key, 
  name varchar(50) unique, 
  passwd varchar(32), 
  account integer 
);

CREATE TABLE Organizations (  
  organizationid serial primary key, 
  name varchar(150) unique, 
  administrator integer references Members(memberid), 
  account integer 
);

CREATE TABLE TransferHistory  
  "from" integer, -- foreign key?
  "to" integer, -- foreign …

我有一个用于存储“任务”的表。任务可以是父项和/或子项。我使用“ ParentID ”作为 FK 引用同一张桌子上的 PK。它是 NULLABLE，所以如果它是NULL它没有父任务。

示例是下面的屏幕截图...

在我的团队中，有人认为创建一个单独的表来存储 ParentID 会更好（对于规范化/最佳实践），从而避免表中出现 NULL 并导致更好的规范化设计。

这会是一个更好的选择吗？或者查询会更困难并导致性能问题？

我们只想从一开始就做好设计，而不是以后再发现问题。

现有表的 SQL-DDL 代码：

CREATE TABLE [Tasks].[TaskDetail]
(
    [TaskDetailID] [int] IDENTITY(1,1) NOT NULL,
    [TaskName] [varchar](50) NOT NULL,
    [TaskDescription] [varchar](250) NULL,
    [IsActive] [bit] NOT NULL CONSTRAINT [DF_TaskDetail_IsActive] DEFAULT ((1)),
    [ParentID] [int] NULL,
    CONSTRAINT [PK_TaskDetail_TaskDetailID] PRIMARY KEY CLUSTERED ([TaskDetailID] ASC),
    CONSTRAINT [FK_TaskDetail_ParentID] FOREIGN KEY([ParentID]) REFERENCES [Tasks].[TaskDetail]([TaskDetailID])
);

我们的所有生产数据库都采用简单恢复模型，对此我们感到非常高兴，因为它完全满足我们的 RPO 和 RTO。

现在我们想为我们的数据库实施 AG DR 解决方案，我们发现完全恢复模型是一个要求。

我的问题是为什么？从理论上讲，AG 或其他 SQL Server DR 解决方案（日志传送、数据库镜像）不应该与简单恢复模型一起使用是否存在任何技术原因？

我刚刚开始了我的第一个在线数据库课程，我有一个家庭作业，从规范列表中创建实体关系图 (ERD)。

规格如下：

1. 公司按部门组织。每个部门都有一个名称、一个唯一编号和管理该部门的特定员工。我们跟踪员工开始管理部门的开始日期。一个部门可能有多个位置。

2. 一个部门控制多个项目，每个项目都有一个名称、唯一编号和一个位置。

3. 我们存储每个员工的姓名、SSN、地址、薪水、性别和 DOB。一名员工被分配到一个部门，但可能从事多个项目，这些项目不一定受同一部门控制。我们会跟踪员工每周为每个项目工作的小时数。我们还跟踪每位员工的直接主管。

4. 为了保险起见，我们希望跟踪每个员工的家属。我们保留每个受抚养人的姓名性别、出生日期以及与员工的关系。

在我的数据库设计课程中，我们学习了关系代数和关系微积分。我可以看到关系代数在哪里有用，因为它与 SQL 密切相关。

我们的教授说，在一些 RDMBS 中，关系微积分被用作 SQL 的替代品，其中大部分已不再存在。关系微积分还有实际用途，还是大部分是理论性的？

例如，一些等价于

CREATE INDEX Listing_Date_Idx ON ACTIVITY(Listing,Date_ DESC,Time_ DESC);

我将数据库与 Visual Studio 2017 连接。当我尝试执行查询时，它显示以下错误：

我使用的连接字符串是：

SqlConnection con = new SqlConnection("Data Source=ANUPAM-DESKTOP\ANUPAM;Integrated Security=True;Connect Timeout=30;Encrypt=False;TrustServerCertificate=True;ApplicationIntent=ReadWrite;MultiSubnetFailover=False"); 

我的代码：

public void exicuteDatabaseQuery(String query)
    {

        con.Open();
        SqlDataAdapter sda = new SqlDataAdapter(query, con);
        sda.SelectCommand.ExecuteNonQuery();
        con.Close();
        MessageBox.Show("Successfull");


    }

    private void Button_Click(object sender, RoutedEventArgs e)
    {
        int id = Convert.ToInt32(___Id_.Text);
        int number = Convert.ToInt32(___Number_.Text);
        String InsertQuery = "INSERT INTO Member (id, number) 
        values('"+id+"','"+number+"')";

        exicuteDatabaseQuery(InsertQuery);
    }

数据库浏览器图像：

我们有一个数据库，其中多个表被分区。这些表的主键（为简洁起见，PK）的形式为

• 交易日期，ID

其中transaction_date是分区键，id是唯一的整数列。如果我们不对表进行分区，那么我们只会使用id作为 PK。

我们还有其他几个表需要外键 (FK) 来引用这些分区表。我无法决定是使用复合 FK，引用 PK 的两列，还是使用单列 FK，引用唯一索引支持的id列。

这两种方法有什么优点/缺点吗？到目前为止，我能想到的唯一因素（我什至可能是错的）是：

• 单列 FK：降低应用程序开发的复杂性。

• 复合 FK：允许在加入 FK 列时消除分区。

我对 SQL Server Always On 的理解有些担忧。请您在需要时纠正我（概念上）：

1. Always On 集群和 Always On 可用性组是 2 个独立的概念。集群是一种 HA 解决方案，而 AG 是一种 DR 解决方案。Always On 群集是否与 Windows 服务器群集相同？

2. 要创建 Always On 群集 - 我们必须启动安装程序并选择“新 SQL Server 故障转移群集安装”，然后在每个新节点上我们需要启动安装程序并选择“添加节点”。集群（有多个节点）在IP地址方面作为一个单元运行，因此应用程序只指向一个IP，如果发生实例崩溃，则故障转移由集群技术处理，不需要更改应用程序IP。此外，用户/登录名是同步的，并且在故障转移的情况下将继续工作。这不能防止磁盘故障，因为所有节点共享同一个磁盘。

3. 假设我们已经有一个 SQL Server 实例（比如服务器 A），那么要为此创建 Always On Clustering，我们需要执行与上述相同的步骤（创建新的故障转移集群安装），然后将服务器 A 添加为节点。对？

4. 假设我们有一个新的 SQL Server 实例（没有 HA/DR）并且计划只配置 AG，那么我们首先需要确保在每个参与节点上启用“故障转移群集”窗口功能。然后右键单击 SQL Server 服务并启用“Always on Availability Groups”。然后在服务器实例上，我们创建 AG 并将数据库配置到组中。这确保了数据库级别的可用性，但是如果发生故障转移，则登录将不再起作用（孤立）。没有共享磁盘，因此主服务器的磁盘崩溃不会导致辅助服务器数据库出现任何问题。此外，客户端应用程序将指向侦听器 IP，侦听器将确保应用程序使用适当的工作服务器。对？

5. 在上述场景中，启用了“故障转移群集”窗口功能，因此群集是 AG 的先决条件吗？Point 2 和 Point 4 中聚类的概念是否相同。

6. 如果我希望使用 Always On (AG) 和故障转移群集配置 HA/DR，那么最佳做法是遵循第 2 点然后是第 4 点还是相反的方式？另外，我们是否应该同时使用虚拟集群名称和监听器，或者如果足够，我们应该使用其中之一吗？

7. “SQL Server 故障转移群集安装”和 Windows …

如果我有一个数百万行的表，并且运行一个更新 50k 行的事务，那么这会对性能产生什么影响？

假设它的索引正确，应该不会花很长时间，但是哪些行被锁定以及该表的使用如何受到影响？

1. 在事务开始后和完成之前是否可以读取事务期间更新的行？
2. 在事务开始后和完成之前是否可以读取事务期间未更新的行？
3. 如果另一个事务开始尝试更改先前未完成的事务正在更改的行，那么该事务会在开始时失败还是在尝试提交之后失败（假设发生冲突）？

我的问题是针对 Postgres 9.3 的；我认为存在差异。