标签: foreign-keys

我不清楚当删除指定选项 CASCADE 的“外键约束”时会发生什么。

例如，考虑这个命令

ALTER TABLE table1 DROP CONSTRAINT foreignKeyToTable2 CASCADE.

在这种情况下，选项 CASCADE 应该做什么？如果我省略它会发生什么？如果我写 RESTRICT 而不是 CASCADE 呢？

注意：此查询示例摘自“Ramez Elmasri，Shamkant B. Navathe - 数据库系统基础知识，第 5 章末尾”。

显示创建表 USERS；我会得到那个结果。

    CREATE TABLE `USERS` (
  `UR_ID` bigint(20) NOT NULL,
  `DEPT_ID` bigint(20) DEFAULT NULL,
  `DN_ID` bigint(20) NOT NULL,
  `CREATED_BY` varchar(45) NOT NULL,
  `LAST_UPDATED_BY` varchar(45) NOT NULL,
  `LAST_UPDATED_DT` datetime NOT NULL,
  `UR_LOGIN_NAME` varchar(255) NOT NULL,
  `TRANS_ID` bigint(20) DEFAULT NULL,
  PRIMARY KEY (`UR_ID`),
  UNIQUE KEY `Uk11` (`UR_LOGIN_NAME`),
  KEY `SYS_C0018877` (`UR_ID`),
  KEY `SYS_C0018878` (`DEPT_ID`),
  KEY `SYS_C0018879` (`DN_ID`),
  **KEY `SYS_C0018880` (`CREATED_BY`),**
  KEY `SYS_C0018881` (`LAST_UPDATED_BY`),
  KEY `SYS_C0018882` (`LAST_UPDATED_DT`),
  KEY `SYS_C0018883` (`UR_LOGIN_NAME`),
  CONSTRAINT `fk_USERS_2` FOREIGN KEY (`DN_ID`) REFERENCES `DESIGNATION` (`DN_ID`) ON DELETE NO ACTION ON UPDATE …

我有以下数据库架构：

父表：

1. id - 主键标识符。
2. 类型 - 多态身份。
3. 名称 - 字符串数据列。

子表 - 继承父表：

1. id - 主键标识符。
2. Parent_id - 父级的外键。
3. 类别 - 字符串数据列。

总结一下，我有两张桌子。Child 表继承自 Parent 并且也有一个外键。

UPD：我真的需要继承和外键。此示例只是一个重现问题的简短演示。

我使用 declarative_base 来声明架构：

# -*- coding: utf-8 -*-

from sqlalchemy import Column, String, Integer, ForeignKey
from sqlalchemy.orm import relationship
from sqlalchemy.ext.declarative import declarative_base
from sqlalchemy import create_engine
from sqlalchemy.orm import sessionmaker

Base = declarative_base()

class Parent(Base):
  __tablename__ = "Parent"
  id = Column(Integer, primary_key=True)
  type = Column(String(250)) …

所以我读了这个问题、答案和评论，但它没有回答我的情况，当列是外键时该怎么办？

这是我创建相关表的原始迁移：

class CreateTemplates < ActiveRecord::Migration[5.1]
  def change
    create_table :templates, id: :uuid do |t|
      t.references :account, type: :uuid, foreign_key: true
      t.string :name
      t.text :info
      t.string :title

      t.timestamps
    end
  end
end

由于 account_id 是一个外键（并标识客户），它将出现在该表的几乎所有（99%）查询中。

现在已经决定名称对于帐户来说应该是唯一的，因此模型已更新：

  validates_uniqueness_of :name, scope: [:account]

所以一旦我添加联合索引：

add_index :templates, [:name, :account_id], unique: true

我应该删除 account_id 上的索引吗？

我问这个问题是因为在 SQLLite （参见this）中，答案似乎是我不需要 account_id 上的单个索引并在第一个位置使用 account_id 创建新索引：

add_index :templates, [:account_id, :name], unique: true

我正在使用 postgres，那么同样的想法也适用吗？

我很惊讶地发现子表有一些父表没有的键，并且 SQL Server 在插入数据时没有给出任何错误。我使用bcp命令将数据从.csv文件加载到父表和子表中。

我可以看到外键约束已启用。

子表中使用的约束是：

ALTER TABLE [dbo].child WITH NOCHECK 
    ADD CONSTRAINT [FK_child_Parent] 
    FOREIGN KEY(company_id) REFERENCES [dbo].[Parent] (company_id)
GO

ALTER TABLE [dbo].child CHECK CONSTRAINT [FK_child_Parent]
GO

当我插入一些记录时，SQL Server 会因违反外键而引发错误，这很好，但我很困惑为什么 SQL Server 在填充此数据时没有引发任何错误？

此外，我通过执行以下查询重新验证了现有记录的外键违规情况，并得到了预期的错误。

ALTER TABLE child
      WITH CHECK CHECK CONSTRAINT ALL
 GO

我正在使用 Django 开发一个网络应用程序。我已经在 MySQL 数据库中创建了表，然后使用检查数据库生成 models.py。我能够毫无问题地获取详细信息并连接到数据库。但是在将值保存到特定表时，显示以下错误

sav_list = List(id=4, item_name ='name1', item_desc='desc1', location='location', reason='rfp',  pid=3)

无法分配“3”：“List.id”必须是“Order”实例。

我的模特

class List(models.Model):
    id = models.IntegerField(db_column='ID', primary_key=True)  # Field name made lowercase.
    item_name = models.CharField(db_column='Item_Name', max_length=255)  # Field name made lowercase.
    item_desc = models.CharField(db_column='Item_Desc', max_length=300)  # Field name made lowercase.
    location = models.CharField(db_column='Location', max_length=100, blank=True, null=True)  # Field name made lowercase.
    reason = models.CharField(db_column='Reason', max_length=100, blank=True, null=True)  # Field name made lowercase.
    pid = models.ForeignKey('Order', models.DO_NOTHING, db_column='PID')  # Field name made lowercase.

class Order(models.Model): …

我有一个赞助应用程序，并尝试在用户赞助孩子后将赞助孩子和用户添加到数据透视表中。

• 孩子可以拥有尽可能多的用户（赞助商），只要他们的插槽允许。
• 如果需要，用户可以赞助一个孩子、多个孩子或多次赞助同一个孩子。

我为赞助者孩子和用户创建了一个数据透视表。在第一个事务中，表中的关系是正确的，但如果用户返回并再次赞助孩子的第二个或第三个插槽，我会收到以下错误：

SQLSTATE[23000]：违反完整性约束：1062 键“PRIMARY”的重复条目“1-1”（23000）

kid_user数据透视表：

public function up()
{
    Schema::create('kid_user', function (Blueprint $table) {
        $table->integer('kid_id')->unsigned()->index();
        $table->foreign('kid_id')->references('id')->on('kids')->onDelete('cascade');
        $table->integer('user_id')->unsigned()->index();
        $table->foreign('user_id')->references('id')->on('users')->onDelete('cascade');
        $table->primary(['kid_id', 'user_id']);
        $table->timestamps();
    });
}

儿童模型：

  public function users() {
        return $this->belongsToMany(User::class)->withTimestamps();
  }

用户型号：

  public function kids(){
       return $this->belongsToMany(Kid::class)->withTimestamps();
  }

用这一行连接到我的控制器中：

        $cin = $request->cin;
        $kidid = $request->kidid;

        $kids = DB::table('kids')->where('cin', $cin)->increment('sponsors_received');
        $user = Auth::user();
        $user->kids()->attach($kidid);
        //$user->kids()->sync($kidid);
;

我目前得到的：

+--------------------+
|   kid_user table   | 
+--------------------+
| *kid_id | *user_id | * = Primary Key
+---------+----------+
| …

我最近开始使用 Django，所以请耐心等待。我有一个有 2 个外键的模型

class Application(models.Model): assessment_owner = models.ForeignKey(User, related_name='assessment_owner') creator = models.ForeignKey(User, related_name='creator')

我正在尝试将名为 tech_lead 的新外键添加到同一模型中，tech_lead 的默认值应该是assessment_owner。稍后，我可以使用数据加载更新 tech_lead 的值，但最初它应该是评估所有者。

通过以下代码片段，Django 在进行迁移时要求默认值，并在各处分配相同的 tech_lead。我想通过代码定义 tech_lead 的默认值，简单的默认属性不起作用。我尝试使用信号 pre_save 和 post_save 但没有成功。

class Application(models.Model):
    assessment_owner = models.ForeignKey(User, related_name='assessment_owner')
    creator = models.ForeignKey(User, related_name='creator')
    tech_lead = models.ForeignKey(User, related_name='tech_lead')

我正在使用 Django 1.11.3 和 postgreSQL。

迁移成功并具有一次性默认值。

错误堆栈 -

环境详情

错误

错误

提前致谢。

最佳实践是通过 ID 而不是通过引用来引用另一个聚合根（请参阅“实现域驱动设计”第 359 页及后续内容）。

// direct reference
class AggregateRootA(val b: AggregateRootB)

// reference by ID (preferred)
class AggregateRootA(val b: AggregateRootBId)

class AggregateRootB(val id: AggregateRootBId)
class AggregateRootBId(val id: Long)

这种解耦的核心论点是每个聚合根应该是一个事务边界。

我想知道在代码中使用id引用时在数据库中使用外键关系是好还是坏。AggregateRootA此约束将强制数据库级别的一致性，因为如果没有 的引用记录，则不可能存在 的数据库记录AggregateRootB。这本质上就是我想要的，因为否则该对象将无效。

除了稍微麻烦一点的测试之外，在这里使用外键还有什么缺点吗？

我正在开发 EF core 2.2 Rest api 项目。我使用 dbfirst 方法和“Scaffold-DbContext”命令创建了模型和上下文。

模型和上下文有效，但我注意到在上下文代码中，外键有显式名称：

    modelBuilder.Entity<TrackingPoints>(entity =>
    {
        entity.HasKey(e => e.IdPosition);

        entity.ToTable("myTable");

        entity.Property(e => e.CaseId).HasColumnName("CaseId");

        entity.HasOne(d => d.IGeoPosition)
            .WithMany(p => p.TrackingPoints)
            .HasForeignKey(d => d.IPositionId)
            .OnDelete(DeleteBehavior.ClientSetNull)
            .HasConstraintName("FK__Track__iGeoP__278EDA44");
    });

（实际表有更多字段，但我保持简短）

我关心的是 FK 名称 (HasConstraintName)。实际上，这段代码包含有关表之间数据关系的信息，但它也有 FK 约束的显式名称。

我注意到，在该数据库的不同实例（开发、预生产...）中，相同的约束具有不同的名称。

我想知道是否必须在数据库的所有实例上为 FK 约束指定相同的名称，或者尽管约束的命名不匹配，映射是否仍能完美地工作。在开发环境中它可以工作，并且 FK 名称与模型中的名称相匹配。在不同的环境中，第一次测试是可以的，但我不知道命名问题是否会产生一些模糊且难以发现的副作用。