lelex ha scritto:

Spero che si capisca + o - quello che volevo dire.

...quello che si capisce è che hai le idee (molto) confuse e non è leggendo qua e la qualche tip che lo si può legare alla rinfusa con altri ed ottenere così le migliori prestazioni.
La decisione se un campo debba ammettere valori NULL o meno esula da tutte le considerazioni che hai fatto e metterci dei valori a caso non cambia lo status delle cose riguardo alle prestazioni.
Un campo NULL lo si implementa quando il valore è SCONOSCIUTO o NON APPLICABILE. In questi casi NULL è NULL. Sicuramente NULL non è 0 o ''.

Bye

---

Modificato da l.bianchi il 02 febbraio 2006 13.37 -

lelex ha scritto:

Ripeto che non è una cosa che ho inventato così ma era scritta in un manuale.

E non ho ragione di dubitarne, così come non ho ragione di dubitare di ciò che indica questo "manuale" senza sapere quale sia (qual'è?) e, cosa più importante di tutte le altre, il contesto in cui è calato ciò che hai molto (troppo) sinteticamente riportato

Comunque la mia domanda era: se le prestazioni migliarano di +
- nel caso citato dal manuale ma senza relazione
- con campo NULL ma con relazione.

Una relazione non ha nulla a che vedere con le prestazioni. E' fuori discussione il fatto che la sola presenza di un vincolo di integrità referenziale penalizza le prestazioni in fase di inserimento/modifica dei dati in quanto il vincolo deve essere preventivamente validato, ma non puoi subordinare la presenza di un vincolo ai requisiti prestazionali che ti si chiede di assicurare.
Partendo dal presupposto che se non ti fosse stato richiesto di assicurare tali "requisiti prestazionali" (come sono misurati e quantificati? su quali baseline?) dubito che avresti scritto un'applicazione prescindendo dalle normali best practice, non puoi subordinare l'integrità dei dati a qualunque altra funzionalità. Altrimenti sarebbe come svitare tutte le lampadine di casa al fine di risparmiare energia elettrica.
La presenza di un vincolo (sia esso di integrità referenziale che un vincolo "di dominio" come la possibilità o meno di ammettere valori NULL) derivano dall'analisi dei requisiti che la base dati deve soddisfare. Al requisito "prestazionale" si affianca quello funzionale e a seconda della fase progettuale in cui ti trovi assume maggior rilevanza uno piuttosto che l'altro.
Ed in quest'ottica la ricerca delle migliori prestazioni la vedo alla fine del ciclo di sviluppo; quella della definizione del modello logico dei dati all'inizio.
Bada bene che ciò non significa che in questa fase puoi fare tutte le cappellate che vuoi tanto alle prestazioni ci pensi dopo. Significa seguire (ma soprattutto applicare) un metodo e non uno zibaldone di tips (seppur validi) nell'ordine in cui ti vengono in mente...

Bye