Come rappresentare una collezione con capacità in un database?

Quali sono i vantaggi o i detrimenti di ciascuno di questi modi?

Vantaggi dell'opzione 1

• Può essere applicato a livello di database concedendo agli utenti privilegi di aggiornamento su B, ma nessun privilegio di inserimento o cancellazione. Ovviamente un utente privilegiato (magari una stored procedure) dovrebbe creare le righe iniziali.
• La capacità, essendo un attributo di A è una colonna di A, che ha senso.

Svantaggi dell'opzione 1

• Nessuno che io conosca.

Vantaggi dell'opzione 2

• La capacità, essendo un attributo di A è una colonna di A, che ha senso.

Svantaggi opzione 2

• L'applicazione (o le applicazioni) deve applicare una regola aziendale che potrebbe essere facilmente applicata a livello di database.

Raccomandazione:

Una combinazione di entrambi:

• Memorizza la capacità di A come una colonna di A.
• Un utente privilegiato (il back-end) creerà tutte le righe in B come la capacità di A.
• Gli utenti normali non possono inserire o eliminare da B, basta aggiornare.
• Quando viene apportata una modifica alla capacità di A, il backend inserisce o elimina righe in modo che il numero di righe corrisponda alla capacità di A.

Esiste un metodo standard per farlo?

Francamente, io non la penso così

Ci sono problemi di prestazioni o di manutenzione?

L'opzione 2 può creare incongruenze dovute a errori di programmazione.

Nota:

Non esiste una cosa come "l'applicazione" . La regola one-app < - > one-DB non si applica al giorno d'oggi quando potenzialmente avrai diversi front-end allo stesso back-end.

Possibilità di aggiungere un trigger per applicare l'opzione 2:

Non so cosa sia il tuo RDBMS ma questo è uno pseudo codice:

create trigger mytrigger before insert on table B for each row
declare
  var c integer;
  var ca integer;
begin
     select count(*) into c from B where id_a = :new.id_a;
     select capacity into ca from A where id = :new.id_a;
     if c > ca then
          RAISE_APPLICATION_ERROR(-20001, 'Cannot Insert mora than '||ca||' rows in this table');
     enf if;
end

Per almeno due motivi, l'opzione # 2 è il vincitore per me (anche se non sono sicuro che questo sia considerato un ragionamento "standard"):

1. Con l'opzione 1, si avranno le righe sprecate / vuote / null che vengono aggiunte per impostazione predefinita ogni volta che viene creata un'istanza dell'entità padre. Non solo questo potenzialmente spreca risorse, ma probabilmente avrai tempi frequenti in cui i risultati delle query devono essere eliminati per tener conto di ciò e potrebbero rendere qualsiasi codice di stored procedure più brutto.

2. Logicamente, non è proprio la responsabilità del DB imporre il vincolo di capacità. Finché l'entità genitore registra la capacità, il tuo modello è completo. Si passa quindi all'app, come si nota, per garantire che i requisiti del modello siano applicati.