1.976 messaggi dal 27 luglio 2005
Contributi
salve,
grigon wrote:
Chiedevo solo se c'è un comando semplice per realizzare l'avverimento della tabella cambiata, tanto per non lavorare sul client quando magari bastava aggiungere o mettere un flag da qualche parte.

no, non c'e'... ripeto, Notification Services dovrebbe in un qualche modo poter gestire la cosa..

La domanda mia ora è: posso passare un file di script come file o devo postare tutto il contenuto?

non ho personalmente compreso la domanda..
saluti

Andrea Montanari
http://www.hotelsole.com - http://www.hotelsole.com/asql/index.php
16 messaggi dal 11 settembre 2009
l12345 ha scritto:
grigon wrote:
".. Attualmente il problema l'ho risolto per il semplice fatto che il
server l'ho creato io. "
... beh se hai risolto, allora ok.


Grazie per la risposta ma, c'è una piccola differenza fra averlo risolto con paradox e doverlo risolvere con sql. O no?
Comunque HO CAPITO, non c'è nessun meccanismo implementato.

Passo a cose più importanti:

Per ogni CLIENTE dovrei, in base agli ordini ricevuti, memorizzare la Data dell'ultimo ordine, la media dei giorni per ordine ricevuto, l'ultimo costo di trasporto e la media dei costi trasporto nonchè il totale peso degli ordini evasi relativi al cliente stesso.
Alla stessa maniera dovrei procedere anche con altri DB: Prodotti, Magazzino, etc.
Questi dati mi servono in un secondo momento per determinare la convenienza o meno del trasporto (in base allo storico) ed eseguire query su totale evaso, etc.
Questo approccio mi sembra però pericoloso, nel senso che, qualora risulti incoerente qualche dato bisogna poter ricalcolare il tutto mentre se ho i dati primitivi i calcoli sono fatti al momento e quindi non possono esistere incoerenze. Il quesito è: posso fare una query su dei dati che devono essere calcolati?

Esempio: voglio conoscere la media delle medie degli ordini dei clienti di una determinata zona. (devo prima calcolare la media cliente per cliente o in alternativa la media di tutti gli ordini relativi ai clienti selezionati)

Fattore fondamentale: il tempo di risposta!

Non sò se mi sono spiegato, spero di sì. Grazie in anticipo. G.Rigon
Modificato da grigon il 14 settembre 2009 08.35 -
60 messaggi dal 30 dicembre 2006
grigon ha scritto:
"Grazie per la risposta ma, c'è una piccola differenza fra averlo risolto con paradox e doverlo risolvere con sql. O no? "
scusa ma non era chiaro a quale server alludessi (s.o., db, application server,..) ;)

stored procedures, views e functions possono tranquillamente affrontare il compito di cui parli, senza la necessità di utilizzare dati precalcolati.

saluti
16 messaggi dal 11 settembre 2009
l12345 ha scritto:
grigon ha scritto:
"Grazie per la risposta ma, c'è una piccola differenza fra averlo risolto con paradox e doverlo risolvere con sql. O no? "
scusa ma non era chiaro a quale server alludessi (s.o., db, application server,..) ;)

stored procedures, views e functions possono tranquillamente affrontare il compito di cui parli, senza la necessità di utilizzare dati precalcolati.

saluti
16 messaggi dal 11 settembre 2009
grigon ha scritto:
l12345 ha scritto:
stored procedures, views e functions possono tranquillamente affrontare il compito di cui parli, senza la necessità di utilizzare dati precalcolati.

saluti


Perfetto, tanto per intenderCi, parliamo di 5000 clienti per 50000 ordini.

Effettivamente il precalcolato non mi è mai piaciuto però, con paradox, non avevo scelta. Alcuni DB li ho dovuti spezzare per mese altrimenti ciao, le risposte alle query arrivavano dopo mezz'ora.

Non è che poi, come vedo spesso, devo rinunciare ad una query perchè il tempo per avere una risposta diventa eccessivo?

Saluti, G.Rigon
60 messaggi dal 30 dicembre 2006
non credo sia possibile darti una risposta 'definitiva' per quanto riguarda le prestazioni 'finali' della tua procedura: troppi fattori in gioco e quelli li conosci solo tu. al di là quindi di mere considerazioni hardware (ovvie), si può dire che non sono certamente numeri (clienti e ordini) tali da impensierire sql server.
credo che dovresti abbozzare la sp, e ottimizzarla se richiesto.
saluti.
16 messaggi dal 11 settembre 2009
Hai pienamente ragione, il fatto è che non vorrei mai integrare l'hardware per colpa del software! Meglio fare a monte le scelte giuste.
Bene, questo è il DB Clienti:

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"
)
)

AgenteID mi serve per collegarmi alla tabella Agenti
LogoID mi serve per collegarmi alla tabella Loghi

e questo è il DB Agenti

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 ,
"Telefono" nvarchar (24) NULL ,
"Cellulare" nvarchar (24) NULL ,
"Foto" "image" NULL ,
"NoteAgente" "ntext" NULL ,
"PathFoto" nvarchar (255) NULL ,
CONSTRAINT "PK_Agenti" PRIMARY KEY CLUSTERED
(
"AgenteID"
)
)

Non ho messo nessun campo calcolato, come suggerito.
Spero vada tutto bene, per ora....
Modificato da grigon il 14 settembre 2009 11.24 -
Modificato da grigon il 14 settembre 2009 11.25 -
60 messaggi dal 30 dicembre 2006
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.

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.