I forum Ricerca FAQ
Fai una domanda
Ultimo messaggio 1 2 3 4
Andrea Montanari
Andrea Montanari
il 14 settembre 2009 alle 12:59
1.976 messaggi dal 27 luglio 2005
Contributi
salve,
l12345 wrote:
beh con una sola tabella si può dire poco, ti pare? comunque direi ok. un dubbio però ce l'ho: l'applicazione
gestisce anche la fatturazione al cliente?
perchè, se è sì, allora potresti separare l'anagrafica 'pura' del cliente dai suoi dati di località per gestire situazioni di diverso indirizzo tra fatturazione e recapito, oppure situazioni di cliente con sedi multiple. a proposito, la p.iva\cod.fisc del cliente? saluti.

aggiungo a quanto correttamente indicato, magari utilizzando i nuovi tipi di dato spaziali (http://msdn.microsoft.com/en-us/library/bb933790.aspx) che SQL Server 2008 implementa, che rendono i calcoli sulle distanze piu' semplici da eseguire?
saluti
Andrea Montanari
http://www.hotelsole.com - http://www.hotelsole.com/asql/index.php
RispondiQuoting
Andrea Montanari
Andrea Montanari
il 14 settembre 2009 alle 13:10
1.976 messaggi dal 27 luglio 2005
Contributi
salve ancora,
grigon wrote:

CREATE TABLE "Clienti" (
"ClienteID" int NOT NULL ,
"NomeCliente" nvarchar (40) NOT NULL ,
"NomeContatto" nvarchar (30) NULL ,
"AgenteID" int NOT NULL ,
"Indirizzo" nvarchar (60) NULL ,
"Città" nvarchar (15) NULL ,
"Provincia" nvarchar (2) NULL ,
"CAP" nvarchar (10) NULL ,
"Paese" nvarchar (15) NULL ,
"Telefono" nvarchar (24) NULL ,
"Cellulare" nvarchar (24) NULL ,
"Fax" nvarchar (24) NULL ,
"GeoLat" real NOT NULL ,
"GeoLng" real NOT NULL ,
"GeoKm" int NOT NULL ,
"LogoID" int NOT NULL ,
"NoteCliente" "ntext" NULL ,
"NoteOrdini" "ntext" NULL ,
"NoteTrasporto" "ntext" NULL ,
"Bloccato" "bit" NOT NULL DEFAULT (0),
"Attivo" "bit" NOT NULL DEFAULT (1),
CONSTRAINT "PK_Clienti" PRIMARY KEY CLUSTERED
(
"ClienteID"
)
)

ferme restando le indicazioni di normalizzazione gia' indicate, per [NoteTrasporto] userei nvarchar(MAX) e non ntext.. il tipo di dato text/ntex e' stato deprecato, ma sopprattutto e' molto piu' "complicato" da gestire manualmente, mentre con i varchar/nvarchar hai a disposizione tutte le funzionalita' utilizzabili con le "stringhe" pure..

considerazione "sintattica".. in SQL Server i quoted identier e' meglio indicarli con "[" e "]", quindi e' preferibile scrivere [ClienteID] rispetto a "ClienteID" ...

considerazione architetturale.. in SQL Server esistono gli "schemi" (http://msdn.microsoft.com/en-us/library/ms190387.aspx) ed e' preferibile sempre indicarli sia al momento del DDL che nelle operazioni CRUD o comunque di accesso agli oggetti, sia per fini prestazionali, in quanto l'assenza di indicazione dello schema comporta da parte del motore la necessaria "scansione" del db "nell'elenco" degli schemi registrati ed utilizzabili dal database principal corrente al fine dell'utilizzo dell'oggetto corretto (possono esistere diversi oggetti con lo stesso nome ma schemi differenti) come anche l'impossibilita' di riutilizzo dei piani di esecuzione di precedenti query, che, ovviamente, anche problematiche relative ad errori di runtime nel caso di impossibilita' di referenziare correttamente gli oggetti ricercati..

saluti
Andrea Montanari
http://www.hotelsole.com - http://www.hotelsole.com/asql/index.php
RispondiQuoting
l12345
l12345
il 14 settembre 2009 alle 13:43
60 messaggi dal 30 dicembre 2006
... certe volte le risposte di A. Montanari nella loro precisione e completezza ti fanno sentire piccolo piccolo ... ;)
RispondiQuoting
grigon
grigon
il 14 settembre 2009 alle 14:33
16 messaggi dal 11 settembre 2009
Grazie per le risposte. Ho modificato così:

CREATE TABLE "Clienti" (
[ClienteID] int NOT NULL ,
[CessionarioID] int NULL ,
[AgenteID] int NOT NULL ,
[LogoID] int NOT NULL ,
"NomeCliente" nvarchar (40) NOT NULL ,
"NomeContatto" nvarchar (30) NULL ,
"Indirizzo" nvarchar (60) NULL ,
"Città" nvarchar (15) NULL ,
"Provincia" nvarchar (2) NULL ,
"CAP" nvarchar (10) NULL ,
"Paese" nvarchar (15) NULL ,
"Telefono" nvarchar (24) NULL ,
"Cellulare" nvarchar (24) NULL ,
"Fax" nvarchar (24) NULL ,
"GeoLat" real NOT NULL ,
"GeoLng" real NOT NULL ,
"GeoKm" int NOT NULL ,
"NoteCliente" nvarchar (255) NULL ,
"NoteOrdini" nvarchar (255) NULL ,
"NoteTrasporto" nvarchar (255) NULL ,
"Bloccato" "bit" NOT NULL DEFAULT (0),
"Attivo" "bit" NOT NULL DEFAULT (0),
CONSTRAINT "PK_Clienti" PRIMARY KEY CLUSTERED
(
[ClienteID]
)
)
GO

CREATE TABLE "Agenti" (
[AgenteID] "int" IDENTITY (1, 1) NOT NULL ,
"Cognome" nvarchar (20) NOT NULL ,
"Nome" nvarchar (10) NOT NULL ,
"Indirizzo" nvarchar (60) NULL ,
"Città" nvarchar (15) NULL ,
"Provincia" nvarchar (15) NULL ,
"CAP" nvarchar (10) NULL ,
"Paese" nvarchar (15) NULL ,
"TelefonoCasa" nvarchar (24) NULL ,
"Estensione" nvarchar (4) NULL ,
"Foto" "image" NULL ,
"NoteAgente" nvarchar (255) NULL ,
"FotoPath" nvarchar (255) NULL ,
CONSTRAINT "PK_Agenti" PRIMARY KEY CLUSTERED
(
[AgenteID]
)
)
GO


CREATE TABLE "Loghi" (
[LogoID] "int" IDENTITY (1, 1) NOT NULL ,
"Logo" "image" NULL ,
"Notes" "ntext" NULL ,
"LogoPath" nvarchar (255) NULL ,
CONSTRAINT "PK_Loghi" PRIMARY KEY CLUSTERED
(
[LogoID]
))
GO


Se cambio nvarchar (255) in nvarchar (max) mi dà un'errore, così pure se dichiaro Geolat ---> geography.

Attualmente uso:

Microsoft SQL Server Management Studio Express 9.00.2047.00
Versione SQL-DM0 8.00.02
RispondiQuoting
grigon
grigon
il 14 settembre 2009 alle 14:45
16 messaggi dal 11 settembre 2009
l12345 ha scritto:
beh con una sola tabella si può dire poco, ti pare? ;)
comunque direi ok. un dubbio però ce l'ho: l'applicazione
gestisce anche la fatturazione al cliente?
perchè, se è sì, allora potresti separare l'anagrafica 'pura' del cliente
dai suoi dati di località per gestire situazioni di diverso indirizzo tra fatturazione e recapito, oppure situazioni di cliente con sedi multiple.
a proposito, la p.iva\cod.fisc del cliente?
saluti.


No, i programmi di contabilità sono una cosa di cui non mi interesso. Io passo una stringa testo che viene elaborata da un programma specifico che tratta tutta la parte economica della filiera del prodotto.
RispondiQuoting
Andrea Montanari
Andrea Montanari
il 14 settembre 2009 alle 14:45
1.976 messaggi dal 27 luglio 2005
Contributi
salve,
grigon wrote:
"NoteCliente" nvarchar (255) NULL ,
"NoteOrdini" nvarchar (255) NULL ,
"NoteTrasporto" nvarchar (255) NULL ,

passi da un ntext ad un nvarchar(255).... ovvio che nella sicurezza della sufficienza e' tutto a posto, ma mi lascia perplesso il cambio.. se hai precedentemente utilizzato ntext probabilmente ti aspetti valori "molto estesi".. ripeto, e senza conoscenza delle tue esigenze, forse nvarchar(MAX) ti lascia ampio margine decisionale per il dimensionamento.. qualora la riga non ecceda gli 8kb tutti i dati restano relegati nella pagina dove la riga viene ospitata, solo diversamente la colonna viene spostata da "in row" in pagine separate..

Attualmente uso:> Microsoft SQL Server Management Studio Express 9.00.2047.00

e SQL Server 2005 che tu stai utilizzando supporta il tipo di dato (MAX) solo se il compatibility level e', ovviamente, impostato a 2005.. diversamente la versione 2005 non supporta i dati spaziali, e comunque, sicuramente, ti consiglio di passare alla versione 2008 viste anche le problematiche di supporto su OS piu' recenti come XP sp3, Vista e 7..
Versione SQL-DM0 8.00.02
lascia perdere DMO ed utilizza in sua sostituzione il componente SMO, in managed code... penso sia tranquillamente utilizzabile anche Delphi..
saluti
saluti
Andrea Montanari
http://www.hotelsole.com - http://www.hotelsole.com/asql/index.php
RispondiQuoting
grigon
grigon
il 14 settembre 2009 alle 15:06
16 messaggi dal 11 settembre 2009
Andrea Montanari ha scritto:
salve,
grigon wrote:
"NoteCliente" nvarchar (255) NULL ,
"NoteOrdini" nvarchar (255) NULL ,
"NoteTrasporto" nvarchar (255) NULL ,

passi da un ntext ad un nvarchar(255).... ovvio che nella sicurezza della sufficienza e' tutto a posto, ma mi lascia perplesso il cambio.. se hai precedentemente utilizzato ntext probabilmente ti aspetti valori "molto estesi".. ripeto, e senza conoscenza delle tue esigenze, forse nvarchar(MAX) ti lascia ampio margine decisionale per il dimensionamento.. qualora la riga non ecceda gli 8kb tutti i dati restano relegati nella pagina dove la riga viene ospitata, solo diversamente la colonna viene spostata da "in row" in pagine separate..

Attualmente uso:> Microsoft SQL Server Management Studio Express 9.00.2047.00

e SQL Server 2005 che tu stai utilizzando supporta il tipo di dato (MAX) solo se il compatibility level e', ovviamente, impostato a 2005.. diversamente la versione 2005 non supporta i dati spaziali, e comunque, sicuramente, ti consiglio di passare alla versione 2008 viste anche le problematiche di supporto su OS piu' recenti come XP sp3, Vista e 7..
Versione SQL-DM0 8.00.02
lascia perdere DMO ed utilizza in sua sostituzione il componente SMO, in managed code... penso sia tranquillamente utilizzabile anche Delphi..
saluti
saluti


Che dire, Montanari sei forte.
Non è che ho capito molto delle osservazioni, forse in pò più in là delle mie capacità, comunque mediterò. Per quanto riguarda lo spazio, meglio stare larghi che ritrovarsi in un imbuto.
Aggiorno SQLServer alla versione 2008, poi ci risentiamo.
Grazie 1000, G.Rigon
RispondiQuoting
Andrea Montanari
Andrea Montanari
il 14 settembre 2009 alle 16:22
1.976 messaggi dal 27 luglio 2005
Contributi
salve,
l12345 wrote:
.. certe volte le risposte di A. Montanari nella loro precisione e completezza ti fanno sentire piccolo piccolo ...

e perche' mai, solo perche' probabilmente sono piu' vecchio? i tuoi contributi sono stati tutti esemplari, a partire dai consigli sull'ottimizzazione, sulla normalizzazione e quant'altro
il bello delle "comunita'" e' proprio questo, il contributo di tutti porta a sinergie incredibili, con "discussioni" che ci fanno crescere tutti.. saluti e continua cosi'
Andrea Montanari
http://www.hotelsole.com - http://www.hotelsole.com/asql/index.php
RispondiQuoting
1 2 3 4

Torna al forum | Feed RSS

ASPItalia.com non è responsabile per il contenuto dei messaggi presenti su questo servizio, non avendo nessun controllo sui messaggi postati nei propri forum, che rappresentano l'espressione del pensiero degli autori.