Newsgroup: it.comp.lang.delphi
Titolo: Micro agenda, appuntamenti e ordini

Ciao a tutti,
     sono a buon punto nella realizzazione di questa micro agendina.
Come ogni agenda, anche questa ha un planner che visualizza gli appuntamenti 
in corso riportando le informazioni principali come il nome dell'azienda, il 
rappresentante e, se e' stato eseguito, il file .pdf (quello famoso del post 
precedente) dell'ordine fatto.
Quindi all'appuntamento e' associata un'azienda a cui si e' fatto un ordine.
Oggi e' capitata un'eccezione, e meno male dico io (perche' la micro agenda 
ancora non e' finita), ovvero l'azienda che fino a settimana scorsa 
proponeva un listino, da oggi ne propone 3 e a seconda di quello che si 
ordina si devono fare 3 ordini distinti da inviare alle 3 (chiamiamole) 
succursali.
Il tutto si traduce che nell'appuntamento devo registrare un'azienda, un 
rappresentante e x ordini.
Il problema lo sto risolvendo con un data base ordini dove ogni ordine ha un 
campo IdAppuntamento che e' l'id univoco dell'appuntamento che ha richiesto 
l'inserimento dell'ordine (in pratica tramite la form dell'appuntamento si 
accede alla form dell'ordine).
Ecco la domanda:
Volendo evitare di usare il campo autoinc del DB, pensavo di utilizzare il 
GUID.
Dalla vostra esperienza cosa consigliate ??
Grazie dell'interesse
Ciao, Daniele
PS : Lo so potevo essere piu' stringato ...... 
__________ Information from ESET NOD32 Antivirus, version of virus signature database 4803 (20100125) __________
The message was checked by ESET NOD32 Antivirus.
http://www.eset.com

Se cerchi nei vecchi post ne troverai uno dove si discute quasi a
livello di flame su questa cosa...
Io sconsiglio ( e non uso!) i guid:
1) non vi e' garanzia dell'univocita'
2) ti porti dietro un campo lunghissimo
E detesto gli autoinc per il fatto che devi reinterrogare il db per
conoscere l'ultimo valore assegnato....
Alcuni db hanno dei sistemi che permettono di generare id numerici
univoci...
Oracle ha le sequences, ad esempio.
In Interbase/Firebird esiste la stessa cosa, solo che si chiamano
generators.
Se invece usi un db che non ha questa cosa, si puo' usare una tabella
di contatori.
A.

 2) ti porti dietro un campo lunghissimo
Assolutamente d'accordo con te. Meglio un id numerico che arriva da 
generators o tabella contatori gestita a software.
Ma tutti quei bytes per una PK.. non ne vedo l'utilitï¿œ.Inoltre un id 
numerico offre prestazioni di gran lunga superiori che un campo stringa 
di 16 bytes..
Ma l'OP non indica quale database usa..
[1]
http://blogs.msdn.com/oldnewthing/archive/2008/06/27/8659071.aspx
Ciao
-- 
Morde

 conoscere l'ultimo valore assegnato....
Non � necessariamente vero. Per esempio con Oracle puoi farti restituire
l'id generato constestualmente alla insert.
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 generators o tabella contatori gestita a software.
Escluderei la tabella dei contatori, a meno che non hanno un valore
applicativo. Se bisogna generare semplicemente delle chiavi primarie per
il campo, � di gran lunga meglio affidarsi al database.
Oracle/Firebird/Postgres sono tutti basati sul meccanismo del campo intero
a cui viene applicato un "generatore". In MySQL invece � possibile
interrogare il db dopo una insert e farsi restituire il "last id". Sono
tutti meccanismi di gran lunga pi� comodi (e veloci) che implementare una
tabella contatori (col rischio di sbagliare).



In sql server basta fare un @@IDENTITY  dopo l'insert per recuperare 
l'ultimo autoinc generato.
Cmq dipende molto dal db usato, non escluderei l'uso degli autoinc a priori.
Andrea 
__________ Informazioni da ESET NOD32 Antivirus, versione del database delle firme digitali 4804 (20100125) __________
Il messaggio � stato controllato da ESET NOD32 Antivirus.
www.nod32.it

 il campo, è di gran lunga meglio affidarsi al database.
Microsoft SqlServer almeno fino alle versioni precedenti alla 2005 non
le ha.
E anche Sybase, per quel che no so, non ha un meccanismo analogo.
Ovviamente se l'op usa un db che le ha, chi se ne fotte della tabella
di contatori...
A.

 Ma l'OP non indica quale database usa..
Avete perfettamente ragione ..... grossa dimendicanza.
Uso le librerie TurboDb della dataweb e delphi 2010.
Grazie ancora
Ciao, Daniele 
__________ Information from ESET NOD32 Antivirus, version of virus signature database 4804 (20100125) __________


> In sql server basta fare un @@IDENTITY  dopo l'insert per recuperare
si..ok...pero', come dicevo prima, devo reinterrogare il database.
PS: ma tutti col nod32??  :-D
A.

 di contatori...
Tutti i database hanno una caratteristica del genere. Almeno i pi�
conosciuti ed utilizzati.


 Idem. Sybase mette a disposizione la keyword "autoincrement".
Correzione: Sybase mette a disposizione "identity" ("auto_increment" � di
MySQL).


 si..ok...pero', come dicevo prima, devo reinterrogare il database.
E quindi? lo fa la macchina, mica ce devi andare tu di persona.


 generators o tabella contatori gestita a software.
Rispetto ad un GUID, secondo me l'autoincrementale con "identity" o 
"generator" ï¿œ preferibile anche per un altro motivo: chiedi a un tuo 
cliente che sta visualizzando magari una pagina Web di dettaglio o di 
modifica di un elemento l'identificativo dello stesso elemento, magari 
passato come parametro nell'URL... si fa senz'altro prima a comunicare 
un numero intero che un GUID, data la lunghezza e la complessitï¿œ non 
indifferente di quest'ultimo. :)
Ciao,
   Marco.
-- 
MARCO BREVEGLIERI
  (
http://www.marco.breveglieri.name
)

 comunicare un numero intero che un GUID
That's good! :-D
-- 
Morde

 modifica di un elemento l'identificativo dello stesso elemento
Personalmente non amo che quell'id sia visibile all'utente. Nel senso che
gli id delle tabelle sono informazioni interne al sistema. Esiste quasi
sempre un "codice", o immesso dall'utente, o generato dal sistema (questa
volta s�, con un tabella di contatori). Per esempio, se sto gestendo degli
ordini, avr� nel record della tabella "ordine" l'id chiave primaria del
record e il numero dell'ordine: un codice o un numero, generato dal
sistema. Il primo (id pk) non � visibile, il secondo (n. ordine) �
informazione applicativa e, ovviamente, conosciuto all'utente. Se ci sono
problemi, l'utente mi fornisce il numero dell'ordine.


 gli id delle tabelle sono informazioni interne al sistema.
Per questo motivo si usano gli encoded url, o sbaglio?
ciao
-- 
Morde

 Personalmente non amo che quell'id sia visibile all'utente.
Quella di cui parlo io non � una visualizzazione volta nello specifico a 
informare l'utente dell'esistenza e del valore dell'identificativo 
interno attribuito a un dato elemento e far presente all'utente stesso 
che questo esiste e il valore che possiede.
Dico solamente che a volte non tutte le persone che richiedono 
assistenza sono in grado di fornirti con precisione le informazioni che 
chiedi, pertanto in alcuni casi faccio prima a chiedere "qual � il 
numero che segue un indirizzo di questo tipo?"
 
http://sito/ordini/visualizza/123456
In questo modo, non ci sono problemi di ambiguit�, e non ho bisogno di 
risalire all'identificativo di un ordine, anche se concordo ovviamente 
che il cliente dovrebbe avere sia buon senso sia le conoscenze 
circostanziate per rispondere correttamente alle domande poste usando il 
vocabolario specifico del suo "business model". :)
Prendendo l'esempio sopra, come dicevo, l'uso di un GUID mi risulta 
deleterio perch� non posso chiedere all'utente di comunicarmi la stessa 
informazione, quando � necessario risalire a un elemento specifico con 
buona sicurezza, avendo un indirizzo di questo tipo:
 
http://sito/ordini/visualizza/AAB8D34B_8E5A_48BC_838F_371F04FB7B56


 ha scritto nel messaggio 
news:4b5ead42$1...@news.x-privat.org...

Non tutto viene codificato per�, solo determinati caratteri, almeno 
attenendosi alla codifica standard degli url.
Mi ci sono imbattuto per l'invio tramite querystring da programma di sms via 
web.
Ciao
Andrea 
__________ Informazioni da ESET NOD32 Antivirus, versione del database delle firme digitali 4805 (20100125) __________



Si potrebbe paventare per�, in casi estremi, un problema di query 
injection...
Dipende sempre dall'utente comunque. Personalmente preferisco che possa 
metter mano a meno possibile.


 E quindi? lo fa la macchina, mica ce devi andare tu di persona.
Hai ragione, Andrea. E' una mia "paturnia".. In pratica, non vi e'
differenza sostanziale tra:
1) chiamare una sequences lato applicazione per calcolare un id e poi
fare la insert...
2) fare la insert e poi interrogare il db per conoscere l'ultimo
valore autoinc...
In entrambi i casi chiami il db 2 volte... :-|
A.


Quello che mi chiedo IO e', come in un precedente th.....
e' come si fa a preferire un GUID che *potrebbe* anche se alla lontana
produrre duplicazioni al valore restituito dai meccanismi dei db,
siano essi sequences o autoinc, le cui probabilita' di duplicazione
sono legate esclusivamente a bug del motore database.....
A.

 che questo esiste e il valore che possiede.
Eh? che hai scritto?? :)


Alberto Salvati ha scritto:

Anche io preferisco usare i valori numerici per gli id, ma � bene sapere
che due GUID uguali sono praticamente impossibili da avere.


> che due GUID uguali sono praticamente impossibili da avere.
http://msdn.microsoft.com/en-us/library/cc246026%28PROT.10%29.aspx
A.

 metter mano a meno possibile.
Qualsiasi condizione logica deve essere verificata e "forzata" 
nell'applicazione: se un utente non puï¿œ accedere a un determinato 
elemento, ad esempio, questo caso va controllato nella logica 
dell'applicazione lato server, e non ï¿œ strettamente correlato al 
passaggio di parametri, a meno che l'indirizzo non contenga una vera e 
propria query.


 Eh? che hai scritto?? :)
Scusa... :)
Volevo semplicemente dire che pu� essere comodo utilizzare l'ID in certe 
occasioni (ad esempio perch� compare in un indirizzo, o viene riportato 
all'interno di un database) per individuare in modo diretto, comodo e 
semplice uno specifico elemento, in casi di emergenza o anche nella 
comunicazione fra colleghi nel team di sviluppo.
A parte questo, poi, concordo con te che il cliente non debba 
generalmente vedere e/o prestare attenzione a questo valore laddove 
compare, ma utilizzare le "chiavi primarie" del proprio ambito (es. il 
numero di una fattura).


 che questo esiste e il valore che possiede.
Marco, xche ogni tanto invece di scrivere in italiano sui la neolingua
di cui parla Orwell in "1984'???
Rotfl!
A.

 
http://msdn.microsoft.com/en-us/library/cc246026%28PROT.10%29.aspx
Io ho scritto: "praticamente impossibili", non "impossibili". Non
essendoci un meccanismo centralizzato per la generazione dei GUID � chiaro
che non pu� esserci garanzia di unicit�, ma � altrettanto vero che i GUID
vengono generati in modo da ridurre al minimo le possibilit� di
collisione. E quel minimo � veramente minimo. 





 metter mano a meno possibile.
Non esiste la soluzione giusta per tutti gli scenari: bisogna 
bilanciare tutti i fattori in gioco. Del resto il nostro lavoro ï¿œ anche 
questo.
Ciao
-- 
Morde

 qua...
In termini pratici, i GUID non sono problematici.
-- 
questo articolo e` stato inviato via web dal servizio gratuito 


 Breveglieri lo fa per praticitï¿œ in un contesto web [...]
In riferimento al problema di "SQL Injection", non vedo problemi 
nell'utilizzare un ID nell'indirizzo URL di una pagina, perchï¿œ la 
protezione da questo tipo di attacchi la si realizza poi con un robusto 
controllo e con una serie di accorgimenti lato server, dove si riceve il 
dato, ad esempio controllando che si tratti di un valore numerico, che 
corrisponda ad un elemento esistente, che l'utente abbia i diritti per 
accedere alla risorsa, ed eseguendo preferibilmente "comandi" al posto 
di "query concatenate", anche per una questione di performance.
Molte di queste "verifiche" di base, anche se ï¿œ bene conoscere a fondo 
la problematica per accerchiare tutti gli altri possibili casi, le fanno 
comunemente la maggior parte dei framework (ad esempio, io utilizzo 
ASP.NET
 MVC che fornisce tutta una serie di meccanismi giï¿œ pronti a 
questo scopo).


 Rotfl!
Non ridere, che chiarezza e prolissit� nello scritto sono tra i due 
problemi che prima o poi dovr� risolvere... :)
