Post by Antonio BudanoNellla tabella MaterialStock la cui chiave primaria è costituita dai primi 6
campi,
Ciao,
6 campi per una chiave e [forse] tutti GUID! Spero tu sia consapevole
che se quella chiave è anche cluster ogni indice si porta dietro un
fardello 96 byte solo per le informazioni di chiave e che ogni relazione
richiede altrettanto spazio!
Non sarebbe il caso di definire una chiave su un surrogato del tipo
MaterialStockID e definire un vincolo univoco sui sei campi?
Post by Antonio Budanoc'è il campo ConfigurationID che è costituito da un GUID (converto in
stringa e genarato dal programma) che deve essere presente nella tabella
Configuration.
Come sarebbe "converto in stringa"? L'uniqueidentifier è uno dei tipi
dato meno ambigui e meglio manipolabili in assoluto, perchè fare un
passo indietro e metterci una stringa????
Post by Antonio BudanoIl record della tabella Configuration (contiene i valori per alcune
caratteristiche di una classe, attribuita al tipo materiale) è presente solo
se il tipo materiale è di tipo configurabile, quindi nel caso in cui il
materiale non è configurabile deve contenere il valore "", oppure un valore
del tipo "00000000-0000-0000-000000000000" che devo inserire nellla tabella
Configuration.
Esistono architetture molto più efficienti che evitano questi campi del
tipo "popolabile solo se quell'altro campo ha un certo valore".
Questo è un errore di architettura, non avrai poi gli strumenti per
garantire l'integrità dei dati se non pesanti trigger e codice complesso.
Hai scritto un paio di post fa "Adesso qualcuno direbbe di definire due
tabelle...". Non ho capito benissimo il significato di Configuration e
non saprei consigliare un'architettura senza informazioni complete, ma
forse si, un'altra tabella potrebbe tornare comoda. Se poi i client che
accedono a questo db lo fanno sempre e solo via viste e stored non ti
devi preoccupare del livello di complessità della base dati, lo strato
"pubblico" [viste e storeds appunto] può essere tranquillamente
denormalizzato.
Post by Antonio BudanoAlternativa è quella di gestire due tabelle per lo stock, una per i
materiali configurabili e una per quelli non, di conseguenza anche i report
che attinge a questa tabella si complicano quando in realtà basterebbe
visualizzare un campo vuoto.
No, personalmente questa scelta non mi sembra affatto necessaria.
Inoltre un report dovrebbe accedere a una vista dedicata e non dovrebbe
creare difficoltà sulla progettazione dell'architettura. L'architettura
va pensata per accogliere al meglio la logica dei dati e non per
rispondere a questioni di interfaccia. Per favorire questo passaggio
esistono appunto viste storeds e funzioni.
Post by Antonio BudanoCREATE TABLE [dbo].[MaterialStock] (
[CompanyID] [udtCompanyID] NOT NULL ,
[PlantID] [udtPlantID] NOT NULL ,
[WarehouseID] [udtWarehouseID] NOT NULL ,
[SeasonID] [udtSeasonID] NOT NULL ,
[MaterialID] [udtMaterialID] NOT NULL ,
[ConfigurationID] [udtConfigurationID] NOT NULL ,
[CreatedOn] [udtDateTime] NULL ,
[CreatedBy] [udtUserID] NULL ,
[ModifiedOn] [udtDateTime] NULL ,
[ModifiedBy] [udtUserID] NULL ,
[AvailableQuantity] [udtQuantity] NULL ,
[AvailableQuantityPreviousFiscalPeriod] [udtQuantity] NULL ,
[AvailableQuantityPreviousFiscalYear] [udtQuantity] NULL ,
[QualityInspectionQuantity] [udtQuantity] NULL ,
[QualityInspectionQuantityPreviousFiscalPeriod] [udtQuantity] NULL ,
[QualityInspectionQuantityPreviousFiscalYear] [udtQuantity] NULL ,
[BlockedQuantity] [udtQuantity] NULL ,
[BlockedQuantityPreviousFiscalPeriod] [udtQuantity] NULL ,
[BlockedQuantityPreviousFiscalYear] [udtQuantity] NULL ,
[TransferQuantity] [udtQuantity] NULL ,
[TransferQuantityPreviousFiscalPeriod] [udtQuantity] NULL ,
[TransferQuantityPreviousFiscalYear] [udtQuantity] NULL ,
[ReturnQuantity] [udtQuantity] NULL ,
[ReturnQuantityPreviousFiscalPeriod] [udtQuantity] NULL ,
[ReturnQuantityPreviousFiscalYear] [udtQuantity] NULL
) ON [PRIMARY]
Questa tabella è molto ben scritta con una chiarissima naming convention
e tutti i tipi dati definiti per bene come User Data Types [in un modo
che a me appare francamente addirittura eccessivo :-D ] però sui
contenuti ha un sacco di cose che non mi piacciono.
Anzitutto ha tutta l'aria di essere una tabella di riepiloghi e io sono
radicalmente contrario a queste strutture [ma esistono pareri favorevoli
molto più autorevoli del mio] se la questione ti interessa puoi dare
un'occhio a questo post:
http://groups.google.it/group/microsoft.public.it.sql/msg/ffc8aad039538d49?hl=it&
Inoltre non amo l'appesantimento dovuto alle informazioni di log
[CreatedOn, CreatedBy...]. Grazie all'univocità a livello di db [e
superiore] dei GUID, questo tipo dato permette di creare strutture del tipo
create table t_Log(RecordID uniqueidentifier,Date datetime,User
uniqeidentifier)
E in questa tabella archiviare tutte le informazioni di modifica di
tutto il db. Osserva come:
1) Si tratta di una struttura denormalizzata poichè RecordID è
virtualmente relazionata a ogni tabella del db e quindi andrà in contro
a casi di non integrità dei dati. Personalmente la cosa non mi tocca,
data la natura delle informazioni e periodicamente faccio un po' di pulizia.
2) La struttura è più potente potendo mantenere tutta la storia delle
modifiche a un record e non solo creazione e ultima modifica, ma,
volendo, creazione, elenco di tutte le modifiche e persino eliminazione.
Inoltre quella tabella ha tutti i campi fuori chiave nullabili, ma cosa
rappresenta un record con tutti i campi nulli??
Post by Antonio BudanoCREATE TABLE [dbo].[Configuration] (
[ConfigurationID] [udtConfigurationID] NOT NULL ,
[CreatedOn] [udtDateTime] NULL ,
[CreatedBy] [udtUserID] NULL ,
[ModifiedOn] [udtDateTime] NULL ,
[ModifiedBy] [udtUserID] NULL ,
[ConfigurationObjectID] [udtConfigurationObjectID] NOT NULL ,
[ConfigurationElementValue1] [udtConfigurationElementValue] NOT NULL ,
[ConfigurationElementValue2] [udtConfigurationElementValue] NOT NULL ,
[ConfigurationElementValue3] [udtConfigurationElementValue] NOT NULL ,
[ConfigurationElementValue4] [udtConfigurationElementValue] NOT NULL ,
[ConfigurationElementValue5] [udtConfigurationElementValue] NOT NULL ,
[ConfigurationElementValue6] [udtConfigurationElementValue] NOT NULL ,
[ConfigurationElementValue7] [udtConfigurationElementValue] NOT NULL ,
[ConfigurationElementValue8] [udtConfigurationElementValue] NOT NULL ,
[ConfigurationElementValue9] [udtConfigurationElementValue] NOT NULL ,
[ConfigurationElementValue10] [udtConfigurationElementValue] NOT NULL ,
[ConfigurationElementValue11] [udtConfigurationElementValue] NOT NULL ,
[ConfigurationElementValue12] [udtConfigurationElementValue] NOT NULL ,
[ConfigurationElementValue13] [udtConfigurationElementValue] NOT NULL ,
[ConfigurationElementValue14] [udtConfigurationElementValue] NOT NULL ,
[ConfigurationElementValue15] [udtConfigurationElementValue] NOT NULL
) ON [PRIMARY]
GO
Una piccola stroncatura anche relativamente a questa tabella :-D
Perchè ci sono quei ConfigurationElementValue1/15?? Una configurazione
ha esattamente 15 elementi?? Non taglia un po' le gambe se salta fuori
il 16 elemento? Perchè non fare una classica master/details?
marc.