여러 테이블에서 기본 키를 참조하는 외래 키?

여러 테이블에서 기본 키를 참조하는 외래 키?

---

직원 데이터베이스 아래에 두 개의 테이블, 즉 employee_ce 및 employee_sn이 있습니다.

둘 다 고유 한 기본 키 열이 있습니다.

deductions라는 또 다른 테이블이 있는데, 그 외래 키 열은 employee_ce 및 employee_sn의 기본 키를 참조합니다. 이게 가능해?

예를 들면

employees_ce
--------------
empid   name
khce1   prince

employees_sn
----------------
empid   name
khsn1   princess

이것이 가능합니까?

deductions
--------------
id      name
khce1   gold
khsn1   silver

---

귀하의 시나리오를 올바르게 이해했다고 가정하면 이것이 올바른 방법입니다.

데이터베이스에 대한 높은 수준의 설명에서 시작하십시오! 직원이 있고 직원은 "ce"직원과 "sn"직원이 될 수 있습니다. 객체 지향 용어로 "employee"클래스가 있으며 "ce employee"와 "sn employee"라는 두 개의 하위 클래스가 있습니다.

그런 다음이 상위 수준 설명을 employees, employees_ce및 employees_sn:의 세 테이블로 변환합니다 .

• employees(id, name)
• employees_ce(id, ce-specific stuff)
• employees_sn(id, sn-specific stuff)

모든 직원이 직원이기 때문에 (duh!) 모든 직원은 employees테이블에 행이 있습니다 . "ce"직원도 employees_ce테이블에 행이 있고 "sn"직원도 employees_sn테이블에 행이 있습니다. employees_ce.id에 외래 키 employees.id것처럼 employees_sn.id입니다.

모든 종류의 직원 (ce 또는 sn)을 참조하려면 employees표를 참조하십시오 . 즉, 문제가 발생한 외래 키는 해당 테이블을 참조해야합니다!

---

두 개의 외래 키 제약 조건을 추가 할 수 있지만 (솔직히 시도해 본 적이 없습니다) 두 테이블에 부모 행이 존재한다고 주장합니다.

대신 두 종업원 하위 유형에 대한 상위 유형을 만든 다음 대신 외래 키를 가리킬 수 있습니다. (물론 두 가지 유형의 직원을 분할해야하는 타당한 이유가 있다고 가정합니다.)

                 employee       
employees_ce     ————————       employees_sn
————————————     type           ————————————
empid —————————> empid <——————— empid
name               /|\          name
                    |  
                    |  
      deductions    |  
      ——————————    |  
      empid ————————+  
      name

type직원 테이블에서 ce또는 sn.

---

사실 제가 직접합니다. 3 개의 다른 테이블에있는 레코드에 대한 주석이 포함 된 'Comments'라는 테이블이 있습니다. 두 솔루션 모두 실제로 원하는 모든 것을 처리하지 않습니다. 귀하의 경우 다음을 수행합니다.

해결책 1 :

1. 각각의 테이블에서 다른 기본값을 갖는 tinyint 필드를 employee_ce 및 employee_sn에 추가합니다 (이 필드는 '테이블 식별자'를 나타내므로이를 tid_ce 및 tid_sn이라고합니다).

2. 테이블의 PK 및 테이블 ID 필드를 사용하여 각 테이블에 고유 인덱스를 만듭니다.

3. Add a tinyint field to your 'Deductions' table to store the second half of the foreign key (the Table ID)

4. Create 2 foreign keys in your 'Deductions' table (You can't enforce referential integrity, because either one key will be valid or the other...but never both:

   ALTER TABLE [dbo].[Deductions]  WITH NOCHECK ADD  CONSTRAINT [FK_Deductions_employees_ce] FOREIGN KEY([id], [fk_tid])
   REFERENCES [dbo].[employees_ce] ([empid], [tid])
   NOT FOR REPLICATION 
   GO
   ALTER TABLE [dbo].[Deductions] NOCHECK CONSTRAINT [FK_600_WorkComments_employees_ce]
   GO
   ALTER TABLE [dbo].[Deductions]  WITH NOCHECK ADD  CONSTRAINT [FK_Deductions_employees_sn] FOREIGN KEY([id], [fk_tid])
   REFERENCES [dbo].[employees_sn] ([empid], [tid])
   NOT FOR REPLICATION 
   GO
   ALTER TABLE [dbo].[Deductions] NOCHECK CONSTRAINT [FK_600_WorkComments_employees_sn]
   GO
   
   employees_ce
   --------------
   empid    name     tid
   khce1   prince    1
   
   employees_sn
   ----------------
   empid    name     tid 
   khsn1   princess  2
   
   deductions
   ----------------------
   id      tid       name  
   khce1   1         gold
   khsn1   2         silver         
   ** id + tid creates a unique index **
   

Solution 2: This solution allows referential integrity to be maintained: 1. Create a second foreign key field in 'Deductions' table , allow Null values in both foreign keys, and create normal foreign keys:

    employees_ce
    --------------
    empid   name
    khce1   prince 

    employees_sn
    ----------------
    empid   name     
    khsn1   princess 

    deductions
    ----------------------
    idce    idsn      name  
    khce1   *NULL*    gold
    *NULL*  khsn1     silver         

Integrity is only checked if the column is not null, so you can maintain referential integrity.

---

I know this is long stagnant topic, but in case anyone searches here is how I deal with multi table foreign keys. With this technique you do not have any DBA enforced cascade operations, so please make sure you deal with DELETE and such in your code.

Table 1 Fruit
pk_fruitid, name
1, apple
2, pear

Table 2 Meat
Pk_meatid, name
1, beef
2, chicken

Table 3 Entity's
PK_entityid, anme
1, fruit
2, meat
3, desert

Table 4 Basket (Table using fk_s)
PK_basketid, fk_entityid, pseudo_entityrow
1, 2, 2 (Chicken - entity denotes meat table, pseudokey denotes row in indictaed table)
2, 1, 1 (Apple)
3, 1, 2 (pear)
4, 3, 1 (cheesecake)

SO Op's Example would look like this

deductions
--------------
type    id      name
1      khce1   gold
2      khsn1   silver

types
---------------------
1 employees_ce
2 employees_sn

---

Technically possible. You would probably reference employees_ce in deductions and employees_sn. But why don't you merge employees_sn and employees_ce? I see no reason why you have two table. No one to many relationship. And (not in this example) many columns.

If you do two references for one column, an employee must have an entry in both tables.

---

Yes, it is possible. You will need to define 2 FKs for 3rd table. Each FK pointing to the required field(s) of one table (ie 1 FK per foreign table).

---

Assuming you must have two tables for the two employee types for some reason, I'll extend on vmarquez's answer:

Schema:

employees_ce (id, name)
employees_sn (id, name)
deductions (id, parentId, parentType, name)

Data in deductions:

deductions table
id      parentId      parentType      name
1       1             ce              gold
2       1             sn              silver
3       2             sn              wood
...

This would allow you to have deductions point to any other table in your schema. This kind of relation isn't supported by database-level constraints, IIRC so you'll have to make sure your App manages the constraint properly (which makes it more cumbersome if you have several different Apps/services hitting the same database).

참고URL : https://stackoverflow.com/questions/668921/foreign-key-referring-to-primary-keys-across-multiple-tables