Come evitare null in chiave primaria? [chiuso]

Usa config id = 0 invece di NULL come indicatore per "blocchi immutabili" e assicurati che ogni record di configurazione abbia un ID > 0. Se si desidera utilizzare la colonna id come chiave esterna, creare un record di configurazione artificiale con id = 0 (che il programma interpreta come "nessuna configurazione").

Tecnicamente (e indipendentemente dal precedente suggerimento), potrebbe essere utile non utilizzare la chiave combinata a due colonne come chiave primaria direttamente, ma per introdurre una colonna aggiuntiva "blockId" per la chiave primaria. In effetti, quando progetto uno schema relazionale, di solito uso una colonna intera del modulo "NomeTabella" per ogni tabella come chiave primaria, il che semplifica molte cose.

Tieni presente che l'introduzione di una colonna blockId risolverà il tuo problema originale solo su alcuni database - alcuni sistemi db consentono valori NULL come parte di UNIQUE CONSTRAINT , altri non consentono questo e alcuni altri lo consentono, ma non garantiscono l'unicità per i record in cui una colonna contiene NULL. Potresti considerare di controllare di cosa è capace il tuo sistema DB, ma consiglio vivamente di usare il mio suggerimento iniziale per risolvere il tuo problema in maniera indipendente dal database.

Il tuo problema è una delle relazioni opzionali tra due siti. Alcuni blocchi hanno configurazioni multiple e altri no. Prendo questo per significare che i blocchi che non hanno più configurazioni non hanno alcuna configurazione. Se hanno una configurazione, il problema scompare.

Hai bisogno di tre tavoli. Uno per i blocchi, uno per le configurazioni e uno per le configurazioni dei blocchi. La terza tabella rappresenta la relazione e contiene due chiavi esterne. Il suo PK è la combinazione delle due chiavi esterne, prese insieme, se si desidera che la relazione sia molti-a-molti. In caso contrario, il PK può essere uno dei due campi.

Quando un determinato blocco non ha alcuna relazione con alcuna configurazione, basta omettere la riga nella terza tabella. Nessun problema! Non ci sono null qui, c'è solo una riga omessa!

Se vuoi saperne di più, guarda "Sesta forma normale".

Difficile da dire dalla tua domanda, ma di solito trovo che ogni tabella dovrebbe avere una sola chiave primaria.

Probabilmente hai bisogno di avere una terza colonna come chiave primaria per la tabella con le due colonne esistenti come FK

Quando crei una chiave primaria tra più FK, puoi scoprire che non diventa univoco man mano che il software si evolve, o per esempio la tua configurazione della pagina cambia nel tempo.

Vedo due potenziali problemi con il tuo progetto:

1. Invertire un'associazione in bianco e nero e le relative configurazioni inserendo una chiave esterna nella parte sbagliata di tale associazione
2. Disporre di due sottotipi di blocchi (immutabili e quelli con configurazioni) in un'unica tabella: "ereditarietà di una tabella"

Sembra che tu stia cercando di implementare un'associazione 1-to-N standard b / w blocks e block_configurations , ma per qualche motivo hai deciso di capovolgerla inserendo la chiave di configurazione in ogni blocco, mentre dovresti fare il contrario, cioè dovresti inserire block_id in block_configurations invece di mettere configuration_id in blocks :

CREATE TABLE blocks (
  block_id CHAR(10),
  is_immutable BIT(1) NOT NULL,
  PRIMARY KEY (block_id)
);

CREATE TABLE block_configurations (
  configuration_id INT(10) AUTO_INCREMENT,
  block_id CHAR(10) NOT NULL,
  PRIMARY KEY (configuration_id),
  FOREIGN KEY block_id_fk(block_id) REFERENCES blocks(block_id)
    ON UPDATE CASCADE
    ON DELETE RESTRICT
);

L'unica cosa che non viene applicata da questo schema è il fatto che i blocchi immutabili non devono avere record di configurazione associati. Puoi farlo usando i trigger, ma la soluzione migliore è usare tabelle configurable_blocks e immutable_blocks separate, poiché in questo caso ci sono due sottotipi di blocchi. Ci sono due modi per farlo: "ereditarietà di tabelle multiple" e "ereditarietà di tabelle di classi". Quello che ho mostrato sopra è una "ereditarietà di una tabella singola", in cui due sottotipi di blocchi sono memorizzati all'interno di una singola tabella.

Ecco un esempio con ereditarietà di più tabelle:

CREATE TABLE immutable_blocks (
  block_id CHAR(10),
  PRIMARY KEY (block_id)
);

CREATE TABLE configurable_blocks (
  block_id CHAR(10),
  PRIMARY KEY (block_id)
);

CREATE TABLE block_configurations (
  configuration_id INT(10) AUTO_INCREMENT,
  block_id CHAR(10) NOT NULL,
  PRIMARY KEY (configuration_id),
  FOREIGN KEY configurable_block_id_fk(block_id) 
    REFERENCES configurable_blocks(block_id)
    ON UPDATE CASCADE
    ON DELETE RESTRICT
);

Questo design ha un altro difetto: se si hanno attributi comuni in due sottotipi di blocchi, è necessario duplicarli su due tabelle. Ecco dove risiede l'ereditarietà delle tabelle delle classi:

CREATE TABLE blocks (
  block_id CHAR(10),
  description VARCHAR(100), -- common field
  PRIMARY KEY (block_id)
);

CREATE TABLE immutable_blocks (
  block_id CHAR(10),
  FOREIGN KEY block_id_fk(block_id) REFERENCES blocks(block_id)
    ON UPDATE CASCADE
    ON DELETE RESTRICT
);

CREATE TABLE configurable_blocks (
  block_id CHAR(10),
  FOREIGN KEY block_id_fk(block_id) REFERENCES blocks(block_id)
    ON UPDATE CASCADE
    ON DELETE RESTRICT
);

CREATE TABLE block_configurations (
  ... same here, still references only configurable_blocks ...
);

Questo design garantisce l'integrità referenziale e consente di separare i campi specifici comuni e sottotipo.

Lettura correlata:

• Antipattern SQL , capitolo "Associazioni polimorfiche": le soluzioni in questo capitolo si applicano a questo caso
• SQL Antipatterns, capitolo "Entity-Attribute-Value" - descrive l'ereditarietà di tabelle single / multiple / class, in relazione al problema di avere sottotipi di qualche entità