Salve a tutti,
ripeto, visto che stai parlando di un database simile a "Northwind", che e' un vecchio database di esempio fornito con SQL Server, ti consiglio di NON ragionare in termini di "memoria" o di occupazione, perche', ripeto, tendenzialmente la valorizzazione di attributi con NULL o "blank" o simili non tende ad "occupare spazio" in maniera allarmante, almeno per quanto riguarda SQL Server...
lo storage engine di SQL Server e' sicuramente piu' intelligente di me relativamente all'occupazione fisica, le pagine di dati, siano esse relative all'indice clustered che contiene effettivamente tutti i dati come anche le pagine degli indici, vengono allocata in maniera molto fine ed intelligente, con metodologie studiate appositamente per ottenere i migliori risultati di I/O e non e' sicuramente la tua colonna con valorizzazione NULL o "blank" a creargli dei problemi... se proprio vuoi, sempre in SQL Server, ti conviene eventualmente ragionare in termini di fill factor delle pagine, per far si che ognuna di esse sia "riempita" al massimo, anche se questo puo' avere indubbie penalizzazioni nei casi di inserimento di nuove righe che comportino degli split di pagine...
Ragiona invece nei normali termini di normalizzazione formale...
e' inutile a mio parere ragionare in termini di "memoria" o similari in quanto il tuo "eventuale" risparmio di allocazione su disco, sempre che tale risparmio sia reale, verra' sostituito in un maggior peso computazionale in termini di risorse sia di I/O che comunque di memoria al momento della proiezione dei dati tramite le query che dovrai effettuare, perche' dovranno essere eseguiti dei join tra tutte le tabelle coinvolte nella proiezione, e quindi non necessariamente avrai dei benefici in questo senso...
anche se tedioso, voglio ripetermi... ragiona nei normali termini di normalizzazione formale e non di allocazione o di memoria...
tieni anche presente che, a volte e con molto "granu salis", viene effettuata anche una denormalizzazione al fine (inverso) di accelerare la proiezione di tabelle "mostruose" (quindi con carichi di allocazione pesanti) proprio per accelerare le operazioni di proiezione che potrebbero comportare un carico computazionale ritenuto eccessivo dal business per le basse performance restituite e per gli eccessivi appesantimenti derivanti dalle operazioni di join, operazioni che potrebbero eventualmente penalizzare troppo la macchina gia' (troppo?) sotto carico dall'attivita' ordinaria... ovviamente queste sono soluzioni da valutare con le pinze...
salutoni omnia
--
Andrea