From matteo a xelefant.com Tue Nov 7 16:00:55 2006 From: matteo a xelefant.com (Tinazzi Matteo) Date: Thu Nov 9 11:00:53 2006 Subject: [Db] [MySQL] problemi esportazione / importazione mysql 5.xx -> 4.0.xx Message-ID: <007001c7027d$87295930$7500a8c0@Matteo> salve alla lista ho un problemino come da topic, praticamente ho una macchina di sviluppo con mysql 5.0.22 e una di produzione con mysql 4.0.26, ora quando devo spostare un db mi trovo di fronte a questo problema, le istruzioni di create table non mi impostano gli autoincrement sui campi sia con phpmyadmin che con mysqldump --compatible=MYSQL40, esempio: esportazione di una tabella con phpmyadmin: CREATE TABLE `t` ( `id` int(11) NOT NULL, PRIMARY KEY (`id`) ) TYPE=MyISAM AUTO_INCREMENT=1 ; esportazione di una tabella con mysqldump --compatible=MYSQL40: CREATE TABLE `t` ( `id` int(11) NOT NULL, PRIMARY KEY (`id`) ) TYPE=MyISAM; invece dovrebbe essere così: CREATE TABLE `t` ( `id` INT( 11 ) NOT NULL AUTO_INCREMENT PRIMARY KEY ) ENGINE = MYISAM ; avete idee su come risolvere? ------------------------------------ Tinazzi Matteo X-Elefant Software s.r.l. Via Treviso 61/13 31057 Silea (Treviso) ICQ# 71-883-066 ------------------------------------ -------------- parte successiva -------------- Un allegato HTML è stato rimosso... URL: http://lists.ziobudda.net/pipermail/db/attachments/20061107/1cb434c8/attachment.html From ml a tassoman.com Thu Nov 9 15:05:27 2006 From: ml a tassoman.com (Tassoman (mailing)) Date: Thu Nov 9 15:10:30 2006 Subject: [Db] [MySQL] problemi esportazione / importazione mysql 5.xx -> 4.0.xx In-Reply-To: <007001c7027d$87295930$7500a8c0@Matteo> References: <007001c7027d$87295930$7500a8c0@Matteo> Message-ID: <1163081127.5368.34.camel@localhost> Il giorno mar, 07/11/2006 alle 16.00 +0100, Tinazzi Matteo ha scritto: > salve alla lista > > ho un problemino come da topic, praticamente ho una macchina di > sviluppo con mysql 5.0.22 e una di produzione con mysql 4.0.26, ora > quando devo spostare un db mi trovo di fronte a questo problema, le > istruzioni di create table non mi impostano gli autoincrement sui > campi sia con phpmyadmin che con mysqldump --compatible=MYSQL40, > esempio: Nelle opzioni di myadmin c'è qualcosa relativo alla creazione degli autoincrement, ma sinceramente non so dirti di preciso. Prova a smanettare con le opzioni "dati" di esportazione. From domenico.lorusso a pleiade.it Fri Nov 10 10:21:42 2006 From: domenico.lorusso a pleiade.it (Domenico L.) Date: Fri Nov 10 10:25:09 2006 Subject: [Db] mysql4 -> impostare a now() il default di una data Message-ID: <455444A6.9070906@pleiade.it> Ciao ragazzi, è possibile farlo? -- Domenico L. icq: 645 44 861 per stupire mezz'ora basta un libro di storia, io cercai di imparare la Treccani a memoria... [F.d.A.] From michel a ziobudda.net Fri Nov 10 10:22:03 2006 From: michel a ziobudda.net (Davide Michel 'ZioBudda' Morelli) Date: Fri Nov 10 10:27:01 2006 Subject: [Db] mysql4 -> impostare a now() il default di una data In-Reply-To: <455444A6.9070906@pleiade.it> References: <455444A6.9070906@pleiade.it> Message-ID: <455444BB.7040907@ziobudda.net> Domenico L. ha scritto: > Ciao ragazzi, > è possibile farlo? > non ho la possibilità di provare, ma se fai un alter table del solo campo e come default metti now () ? Ciao -- Michel 'ZioBudda' Morelli michel@ziobudda.net http://www.ziobudda.net ICQ: 58351764 - Skype: zio_budda http://www.phpbook.it FAX: 0291390660 http://www.ajaxblog.it TEL: 3939890025 From domenico.lorusso a pleiade.it Fri Nov 10 10:38:22 2006 From: domenico.lorusso a pleiade.it (Domenico L.) Date: Fri Nov 10 10:41:48 2006 Subject: [Db] mysql4 -> impostare a now() il default di una data In-Reply-To: <455444BB.7040907@ziobudda.net> References: <455444A6.9070906@pleiade.it> <455444BB.7040907@ziobudda.net> Message-ID: <4554488E.1060500@pleiade.it> Davide Michel 'ZioBudda' Morelli ha scritto: > Domenico L. ha scritto: >> Ciao ragazzi, >> è possibile farlo? >> > > non ho la possibilità di provare, ma se fai un alter table del solo > campo e come default metti now () ? mi mette 0000-00-00 (avevo già provato :-) ) non ho capito se sbaglio io qualcosa o proprio non si può... ALTER TABLE `mytab` CHANGE `myfield` `myfield` DATE DEFAULT "NOW()"; -- Domenico L. icq: 645 44 861 per stupire mezz'ora basta un libro di storia, io cercai di imparare la Treccani a memoria... [F.d.A.] From michel a ziobudda.net Fri Nov 10 10:38:46 2006 From: michel a ziobudda.net (Davide Michel 'ZioBudda' Morelli) Date: Fri Nov 10 10:43:23 2006 Subject: [Db] mysql4 -> impostare a now() il default di una data In-Reply-To: <4554488E.1060500@pleiade.it> References: <455444A6.9070906@pleiade.it> <455444BB.7040907@ziobudda.net> <4554488E.1060500@pleiade.it> Message-ID: <455448A6.4020608@ziobudda.net> Domenico L. ha scritto: > Davide Michel 'ZioBudda' Morelli ha scritto: >> Domenico L. ha scritto: >>> Ciao ragazzi, >>> è possibile farlo? >>> >> >> non ho la possibilità di provare, ma se fai un alter table del solo >> campo e come default metti now () ? > mi mette 0000-00-00 (avevo già provato :-) ) non ho capito se sbaglio > io qualcosa o proprio non si può... > > ALTER TABLE `mytab` CHANGE `myfield` `myfield` DATE DEFAULT "NOW()"; Senza virgolette ??? http://dev.mysql.com/doc/refman/5.0/en/timestamp-4-1.html Ciao -- Michel 'ZioBudda' Morelli michel@ziobudda.net http://www.ziobudda.net ICQ: 58351764 - Skype: zio_budda http://www.phpbook.it FAX: 0291390660 http://www.ajaxblog.it TEL: 3939890025 From michel a ziobudda.net Fri Nov 10 10:39:00 2006 From: michel a ziobudda.net (Davide Michel 'ZioBudda' Morelli) Date: Fri Nov 10 10:43:38 2006 Subject: [Db] mysql4 -> impostare a now() il default di una data In-Reply-To: <4554488E.1060500@pleiade.it> References: <455444A6.9070906@pleiade.it> <455444BB.7040907@ziobudda.net> <4554488E.1060500@pleiade.it> Message-ID: <455448B4.1010801@ziobudda.net> Domenico L. ha scritto: > Davide Michel 'ZioBudda' Morelli ha scritto: >> Domenico L. ha scritto: >>> Ciao ragazzi, >>> è possibile farlo? >>> >> >> non ho la possibilità di provare, ma se fai un alter table del solo >> campo e come default metti now () ? > mi mette 0000-00-00 (avevo già provato :-) ) non ho capito se sbaglio > io qualcosa o proprio non si può... > > ALTER TABLE `mytab` CHANGE `myfield` `myfield` DATE DEFAULT "NOW()"; Senza virgolette ??? http://dev.mysql.com/doc/refman/5.0/en/timestamp-4-1.html Ciao -- Michel 'ZioBudda' Morelli michel@ziobudda.net http://www.ziobudda.net ICQ: 58351764 - Skype: zio_budda http://www.phpbook.it FAX: 0291390660 http://www.ajaxblog.it TEL: 3939890025 From domenico.lorusso a pleiade.it Fri Nov 10 11:13:35 2006 From: domenico.lorusso a pleiade.it (Domenico L.) Date: Fri Nov 10 11:17:14 2006 Subject: [Db] mysql4 -> impostare a now() il default di una data In-Reply-To: <455448B4.1010801@ziobudda.net> References: <455444A6.9070906@pleiade.it> <455444BB.7040907@ziobudda.net> <4554488E.1060500@pleiade.it> <455448B4.1010801@ziobudda.net> Message-ID: <455450CF.4060408@pleiade.it> Davide Michel 'ZioBudda' Morelli ha scritto: > > Senza virgolette ??? > http://dev.mysql.com/doc/refman/5.0/en/timestamp-4-1.html > > Ciao senza mi ritorna errore avevo già provato, ho provato anche con curdate() perché infondo il campo è di tipo date e non timestamp... poi io uso una mysql 4.0 (sooooooob!) -- Domenico L. icq: 645 44 861 per stupire mezz'ora basta un libro di storia, io cercai di imparare la Treccani a memoria... [F.d.A.] From michel a ziobudda.net Fri Nov 10 11:16:42 2006 From: michel a ziobudda.net (Davide Michel 'ZioBudda' Morelli) Date: Fri Nov 10 11:21:20 2006 Subject: [Db] mysql4 -> impostare a now() il default di una data In-Reply-To: <455450CF.4060408@pleiade.it> References: <455444A6.9070906@pleiade.it> <455444BB.7040907@ziobudda.net> <4554488E.1060500@pleiade.it> <455448B4.1010801@ziobudda.net> <455450CF.4060408@pleiade.it> Message-ID: <4554518A.5050105@ziobudda.net> Domenico L. ha scritto: > senza mi ritorna errore avevo già provato, ho provato anche con > curdate() perché infondo il campo è di tipo date e non timestamp... > poi io uso una mysql 4.0 (sooooooob!) > http://sql-info.de/mysql/gotchas.html#1_7 Ciao Michel 'ZioBudda' Morelli michel@ziobudda.net http://www.ziobudda.net ICQ: 58351764 - Skype: zio_budda http://www.phpbook.it FAX: 0291390660 http://www.ajaxblog.it TEL: 3939890025 From domenico.lorusso a pleiade.it Fri Nov 10 11:27:24 2006 From: domenico.lorusso a pleiade.it (Domenico L.) Date: Fri Nov 10 11:31:25 2006 Subject: [Db] mysql4 -> impostare a now() il default di una data In-Reply-To: <4554518A.5050105@ziobudda.net> References: <455444A6.9070906@pleiade.it> <455444BB.7040907@ziobudda.net> <4554488E.1060500@pleiade.it> <455448B4.1010801@ziobudda.net> <455450CF.4060408@pleiade.it> <4554518A.5050105@ziobudda.net> Message-ID: <4554540C.8080707@pleiade.it> Davide Michel 'ZioBudda' Morelli ha scritto: > Domenico L. ha scritto: >> senza mi ritorna errore avevo già provato, ho provato anche con >> curdate() perché infondo il campo è di tipo date e non timestamp... >> poi io uso una mysql 4.0 (sooooooob!) >> > > http://sql-info.de/mysql/gotchas.html#1_7 ah ecco.. non si può ma c'è il trucco... vedo di farmelo andar bene grazie mille!! ciao -- Domenico L. icq: 645 44 861 per stupire mezz'ora basta un libro di storia, io cercai di imparare la Treccani a memoria... [F.d.A.] From ml a tassoman.com Sat Nov 11 10:56:52 2006 From: ml a tassoman.com (Tassoman (mailing)) Date: Sat Nov 11 11:01:46 2006 Subject: [Db] mysql4 -> impostare a now() il default di una data In-Reply-To: <4554540C.8080707@pleiade.it> References: <455444A6.9070906@pleiade.it> <455444BB.7040907@ziobudda.net> <4554488E.1060500@pleiade.it> <455448B4.1010801@ziobudda.net> <455450CF.4060408@pleiade.it> <4554518A.5050105@ziobudda.net> <4554540C.8080707@pleiade.it> Message-ID: <1163239013.6529.10.camel@localhost> Il giorno ven, 10/11/2006 alle 11.27 +0100, Domenico L. ha scritto: > Davide Michel 'ZioBudda' Morelli ha scritto: > > Domenico L. ha scritto: > >> senza mi ritorna errore avevo già provato, ho provato anche con > >> curdate() perché infondo il campo è di tipo date e non timestamp... > >> poi io uso una mysql 4.0 (sooooooob!) > >> > > > > http://sql-info.de/mysql/gotchas.html#1_7 > ah ecco.. non si può ma c'è il trucco... vedo di farmelo andar bene > grazie mille!! > > ciao Da qualche parte avevo letto che facendo una insert o una update, il primo campo datetime che trova lo aggiornava in automatico senza passar nulla. Ma forse usando autoincrement? Oppure era roba della old 3.23.22 ? -- Blogging humanum est, Tassoman ovest. http://blog.tassoman.com From domenico.lorusso a pleiade.it Mon Nov 13 15:35:01 2006 From: domenico.lorusso a pleiade.it (Domenico L.) Date: Mon Nov 13 15:39:00 2006 Subject: [Db] Mysql e indici Message-ID: <45588295.4070306@pleiade.it> Ciao ragazzi, una domandina succosa... In teoria se io ho un indice su 3 campi chiave gerarchici tipo: codiceImpresa, codiceUfficio, CodiceDipendente non è necessario creare degli indici parziali, perché cmq se voglio tutti i membri di un ufficio mi basta arriavare al ramo dell'ufficio e poi scendere... è così anche in mysql??? ciao -- Domenico L. icq: 645 44 861 per stupire mezz'ora basta un libro di storia, io cercai di imparare la Treccani a memoria... [F.d.A.] From cristiano a verondini.it Mon Nov 13 16:36:06 2006 From: cristiano a verondini.it (Cristiano Verondini) Date: Mon Nov 13 16:41:38 2006 Subject: [Db] Mysql e indici In-Reply-To: <45588295.4070306@pleiade.it> References: <45588295.4070306@pleiade.it> Message-ID: On 13/nov/06, at 15:35, Domenico L. wrote: > In teoria se io ho un indice su 3 campi chiave gerarchici tipo: > > codiceImpresa, codiceUfficio, CodiceDipendente > > non è necessario creare degli indici parziali, perché cmq se voglio > tutti i membri di un ufficio mi basta arriavare al ramo > dell'ufficio e poi scendere... è così anche in mysql??? Solo se la where è fatta su parti dell'indice iniziale, quindi nell'ordine: (1) codiceImpresa (2) codiceImpresa, codiceUfficio (3) codiceImpresa, codiceUfficio, CodiceDipendente Cris -- Cristiano Verondini http://www.verondini.it --- [ICQ 114 190] From domenico.lorusso a pleiade.it Mon Nov 13 17:30:14 2006 From: domenico.lorusso a pleiade.it (Domenico L.) Date: Mon Nov 13 17:34:19 2006 Subject: [Db] Mysql e indici In-Reply-To: References: <45588295.4070306@pleiade.it> Message-ID: <45589D96.1070704@pleiade.it> Cristiano Verondini ha scritto: >> codiceImpresa, codiceUfficio, CodiceDipendente >> >> non è necessario creare degli indici parziali, perché cmq se voglio >> tutti i membri di un ufficio mi basta arriavare al ramo dell'ufficio >> e poi scendere... è così anche in mysql??? > > In teoria se io ho un indice su 3 campi chiave gerarchici tipo: > > Solo se la where è fatta su parti dell'indice iniziale, quindi > nell'ordine: > > (1) codiceImpresa > (2) codiceImpresa, codiceUfficio > (3) codiceImpresa, codiceUfficio, CodiceDipendente > > sì, immaginavo, ho detto gerarchico mica per niente 8-) ciauz -- Domenico L. icq: 645 44 861 per stupire mezz'ora basta un libro di storia, io cercai di imparare la Treccani a memoria... [F.d.A.] From ml a tassoman.com Tue Nov 14 22:12:36 2006 From: ml a tassoman.com (Tassoman (mailing)) Date: Tue Nov 14 22:18:13 2006 Subject: [Db] [mySQL] se non =?iso-8859-1?q?c=27=E8?= crealo! Message-ID: <1163538756.5327.37.camel@localhost> Ciao a tutti, vorrei tenere un campo di testo (char o varchar) come chiave unica di una tabella, ed un int autoincrement come chiave primaria. È corretto quindi usare l'estensione REPLACE di mysql per evitare errori di campo duplicato se facessi una INSERT ? Oppure è più corretto fare una query prima alla ricerca del campo di testo unico, per poi eventualmente inserirlo in caso mancante? id int primary nome char unique Su un altra tabella poi mi preoccuperò di salvare i dati che variano (ho bisogno di uno storico) tramite le insert, relazionate 1/n al nome unico. È corretto come approccio no? Piuttosto che crearmi centinaia di record che contengono tutti lo stesso nome. Altrimenti sai come lievita il DB ? -- Blogging humanum est, Tassoman ovest. http://blog.tassoman.com From domenico.lorusso a pleiade.it Wed Nov 15 08:34:40 2006 From: domenico.lorusso a pleiade.it (Domenico L.) Date: Wed Nov 15 08:38:53 2006 Subject: [Db] [mySQL] se non =?UTF-8?B?YyfDqCBjcmVhbG8h?= In-Reply-To: <1163538756.5327.37.camel@localhost> References: <1163538756.5327.37.camel@localhost> Message-ID: <455AC310.70802@pleiade.it> Tassoman (mailing) ha scritto: > id int primary > nome char unique > > Su un altra tabella poi mi preoccuperò di salvare i dati che variano (ho > bisogno di uno storico) tramite le insert, relazionate 1/n al nome > unico. È corretto come approccio no? > più o meno [vedi sotto] in mysql ci sono 2 sintassi per fare insert o update in unica istruzione dipende dalla versione, cmq è sempre meglio usare un'unica istruzione piuttosto che 2 per vari motivi: - la replace è atomica - non devi scrivere codice php - è più pulito Problema: - non è portabile, ma tanto neppure gli autoincrement lo sono quindi una rimessa a posto la devi sempre fare e, per esempio, anche in oracle esiste una funzione simile alla replace che si chiama merge, questo vuol dire che in caso di migrazione devi cambiare un'isturzione sql e non il codice. L'utilizzo dei campi numerici autoincrement come chiavi primarie è un approccio ampiamente superato e che spesso da più problemi che vantaggi. Se il campo nome è unique (e magari not null) perché non fai diventare questo chiave primaria e butti via il campo id? Però bisogna fare attenzione ad essere certi che il campo nome sia sempre unique e capire se deve esserlo case sensitive o meno (mario e Mario sono la stessa chiave o no?) ciao -- Domenico L. icq: 645 44 861 per stupire mezz'ora basta un libro di storia, io cercai di imparare la Treccani a memoria... [F.d.A.] From michel a ziobudda.net Wed Nov 15 10:06:41 2006 From: michel a ziobudda.net (Davide Michel 'ZioBudda' Morelli) Date: Wed Nov 15 10:12:12 2006 Subject: [Db] [mySQL] se non =?ISO-8859-15?Q?c=27=E8_crealo!?= In-Reply-To: <455AC310.70802@pleiade.it> References: <1163538756.5327.37.camel@localhost> <455AC310.70802@pleiade.it> Message-ID: <455AD8A1.404@ziobudda.net> Domenico L. ha scritto: > > L'utilizzo dei campi numerici autoincrement come chiavi primarie è un > approccio ampiamente superato e che spesso da più problemi che vantaggi. Ciao, spieghi meglio questo concetto ? Grazie. M. -- Michel 'ZioBudda' Morelli michel@ziobudda.net Consulenza sistemistica in ambito OpenSource. Sviluppo applicazioni web dinamiche (LAMP+Ajax) Telefono: +39-0240706096 -- Fax: +39-0291390660 http://www.ziobudda.net ICQ: 58351764 http://www.ziobuddalabs.it Skype: zio_budda http://www.ajaxblog.it From marcello a vezz.it Wed Nov 15 10:23:19 2006 From: marcello a vezz.it (Marcello Vezzelli) Date: Wed Nov 15 10:28:58 2006 Subject: [Db] [mySQL] se non =?ISO-8859-15?Q?c=27=E8_crealo!?= In-Reply-To: <455AD8A1.404@ziobudda.net> References: <1163538756.5327.37.camel@localhost> <455AC310.70802@pleiade.it> <455AD8A1.404@ziobudda.net> Message-ID: <455ADC87.50800@vezz.it> Davide Michel 'ZioBudda' Morelli ha scritto: > >> L'utilizzo dei campi numerici autoincrement come chiavi primarie è un >> approccio ampiamente superato e che spesso da più problemi che vantaggi. > > Ciao, spieghi meglio questo concetto ? Anche perché è da una vita che uso campi autoincrementanti come chiavi primarie e una frase del genere mi inquieta. Ciao Marcello From ml a tassoman.com Wed Nov 15 10:31:16 2006 From: ml a tassoman.com (Tassoman (mailing)) Date: Wed Nov 15 10:36:55 2006 Subject: [Db] [mySQL] se non =?ISO-8859-1?Q?c'=E8?= crealo! In-Reply-To: <455ADC87.50800@vezz.it> References: <1163538756.5327.37.camel@localhost> <455AC310.70802@pleiade.it> <455AD8A1.404@ziobudda.net> <455ADC87.50800@vezz.it> Message-ID: <1163583076.5312.12.camel@localhost> Il giorno mer, 15/11/2006 alle 10.23 +0100, Marcello Vezzelli ha scritto: > > Ciao, spieghi meglio questo concetto ? > > Anche perché è da una vita che uso campi autoincrementanti come chiavi > primarie e una frase del genere mi inquieta. Potrebbe anche essere sorpassato, ma per quanto ne so credo sia il più rapido per fare selezioni e join. -- Blogging humanum est, Tassoman ovest. http://blog.tassoman.com From cristiano a verondini.it Wed Nov 15 11:18:22 2006 From: cristiano a verondini.it (Cristiano Verondini) Date: Wed Nov 15 11:23:49 2006 Subject: =?UTF-8?Q?Re:_=5BDb=5D_=5BmySQL=5D_se_non_c'=C3=A8_crea?= =?UTF-8?Q?lo!?= References: <1163538756.5327.37.camel@localhost> <455AC310.70802@pleiade.it> Message-ID: <018801c7089f$82092c50$6301a8c0@IdeaFutura.local> >> L'utilizzo dei campi numerici autoincrement come chiavi primarie è un >> approccio ampiamente superato e che spesso da più problemi che >> vantaggi. Non mi risulta. L'utilizzo di chiavi surrogate ha una serie di vantaggi, non ultimo quello delle performances durante i join. Cris -- Cristiano Verondini http://www.verondini.it --- [ICQ: 114 190] From mailinglist a francescoreitano.it Wed Nov 15 12:03:19 2006 From: mailinglist a francescoreitano.it (Mailinglist - Francesco Reitano) Date: Wed Nov 15 12:08:55 2006 Subject: [Db] [mySQL] se non =?UTF-8?B?YyfDqCBjcmVhbG8h?= In-Reply-To: <455AC310.70802@pleiade.it> References: <1163538756.5327.37.camel@localhost> <455AC310.70802@pleiade.it> Message-ID: <455AF3F7.9030706@francescoreitano.it> Domenico L. ha scritto: > L'utilizzo dei campi numerici autoincrement come chiavi primarie è un > approccio ampiamente superato e che spesso da più problemi che vantaggi. > ipotesi: non è che essendo un devoto di Oracle (credo) attacchi il modo di indicizzare di mysql? From angelo.galleja a email.it Wed Nov 15 12:24:37 2006 From: angelo.galleja a email.it (Angelo Galleja) Date: Wed Nov 15 12:30:18 2006 Subject: [Db] [mySQL] se non c =?UTF-8?B?w6ggY3JlYWxvIQ==?= In-Reply-To: <018801c7089f$82092c50$6301a8c0@IdeaFutura.local> References: <1163538756.5327.37.camel@localhost> <455AC310.70802@pleiade.it> <018801c7089f$82092c50$6301a8c0@IdeaFutura.local> Message-ID: <455AF8F5.9090804@email.it> Cristiano Verondini ha scritto: >>> L'utilizzo dei campi numerici autoincrement come chiavi primarie è un >>> approccio ampiamente superato e che spesso da più problemi che >>> vantaggi. > > Non mi risulta. L'utilizzo di chiavi surrogate ha una serie di > vantaggi, non ultimo quello delle performances durante i join. hai dei dati a supporto di questa affermazione? tempo fa avevo fatto due prova solo che non mi ricordo se ho conservato i risultati ... From matteo.giacomazzi a gmail.com Wed Nov 15 12:34:48 2006 From: matteo.giacomazzi a gmail.com (Matteo Giacomazzi) Date: Wed Nov 15 12:47:30 2006 Subject: =?ISO-8859-1?Q?Re:_[Db]_[mySQL]_se_non_c_=E8_crealo!?= In-Reply-To: <455AF8F5.9090804@email.it> References: <1163538756.5327.37.camel@localhost> <455AC310.70802@pleiade.it> <018801c7089f$82092c50$6301a8c0@IdeaFutura.local> <455AF8F5.9090804@email.it> Message-ID: 2006/11/15, Angelo Galleja : > > > Non mi risulta. L'utilizzo di chiavi surrogate ha una serie di > > vantaggi, non ultimo quello delle performances durante i join. > > hai dei dati a supporto di questa affermazione? > tempo fa avevo fatto due prova solo che non mi ricordo se ho conservato > i risultati ... Stai chiedendo se ci sono dati a supporto del fatto che un confronto tra interi è più performante di un confronto tra altri tipi di dato (e.g. stringhe)? -- Matteo -------------- parte successiva -------------- Un allegato HTML è stato rimosso... URL: http://lists.ziobudda.net/pipermail/db/attachments/20061115/21938723/attachment.htm From domenico.lorusso a pleiade.it Wed Nov 15 13:05:40 2006 From: domenico.lorusso a pleiade.it (Domenico L.) Date: Wed Nov 15 13:09:54 2006 Subject: [Db] [mySQL] se non =?ISO-8859-15?Q?c=27=E8_crealo!?= In-Reply-To: <455AD8A1.404@ziobudda.net> References: <1163538756.5327.37.camel@localhost> <455AC310.70802@pleiade.it> <455AD8A1.404@ziobudda.net> Message-ID: <455B0294.1060900@pleiade.it> Davide Michel 'ZioBudda' Morelli ha scritto: > Domenico L. ha scritto: >> >> L'utilizzo dei campi numerici autoincrement come chiavi primarie è un >> approccio ampiamente superato e che spesso da più problemi che vantaggi. > > Ciao, spieghi meglio questo concetto ? Lasciando perdere le polemiche che mi sembrano fuori luogo, il concetto non ha nulla a che vedere con il rdbms di riferimento e non si rifà neppure a problemi di performance. Le basi dati dovrebbero essere ben organizzate e "facilemente" fruibili, l'utilizzo abnorme di chiavi surrogate porta spesso ad una crescita di join per raccimolare i dati; e, non vi porto i dati perché queste sono cose note, una join è molto più pesante di un confronto tra attributi, solitamente si tende a dire che il peso dei confronti è trascurabile. Ora facciamo un esempio che forse spiega meglio quello che voglio dire: Se per me è chiave la sequenza di 12 caratteri che mi identifica regione-provincia-comune-filiale, suddiviso in 4 campi, se decido di portarmi appresso questi 4 campi nelle tabelle di dettaglio (quelle che per intenderci sono legate 1-n) quindi tabella padre: regione char(3) provincia char(3) comune char(3) filiale char(3) .... tabella figlo: regione char(3) provincia char(3) comune char(3) filiale char(3) .... Se voglio estrarre tutti i record (magari aggregati) dalla tabella figlio *non* devo fare una join ma una semplice where Inoltre è più facile interpretare i dati grezzi (e per noi non è cosa da poco) Terzo, se hai già una chiave (come il caso preso in oggetto) pensi che aggiungere un campo non faccia cmq levitare la base dati, sono cmq di solito levitazioni trascurabili, a questo punto val la pena chiedersi quanto è lungo il campo testuale e quanto spesso viene modificato (se viene modificato) E' ovvio che se il campo per quanto univoco è a lunghezza e subisce molte modifiche usarlo come chiave primaria di una foreign key è poco utile. Tuttavia sempre a livello concettuale (ma su questo non so se mysql ti da supporot) tieni primay il campo nome e unque il campo id usando quest'ultimo come campo padre nelle FK N.B. l'implementazione che ho mostrato della tabella padre e figlio *è* in terza forma normale. Spero di aver chiarito, mi spiace di non aver risposto prima ma ero impegnato ciao -- Domenico L. icq: 645 44 861 per stupire mezz'ora basta un libro di storia, io cercai di imparare la Treccani a memoria... [F.d.A.] From domenico.lorusso a pleiade.it Wed Nov 15 13:08:29 2006 From: domenico.lorusso a pleiade.it (Domenico L.) Date: Wed Nov 15 13:12:43 2006 Subject: [Db] [mySQL] se non =?ISO-8859-15?Q?c=27=E8_crealo!?= In-Reply-To: <455B0294.1060900@pleiade.it> References: <1163538756.5327.37.camel@localhost> <455AC310.70802@pleiade.it> <455AD8A1.404@ziobudda.net> <455B0294.1060900@pleiade.it> Message-ID: <455B033D.8050509@pleiade.it> Domenico L. ha scritto: > > Se voglio estrarre tutti i record (magari aggregati) dalla tabella > figlio *non* devo fare una join ma una semplice where intendevo ovviamente tutti i record di un comune o di una provincia o di un regione :-) -- Domenico L. icq: 645 44 861 per stupire mezz'ora basta un libro di storia, io cercai di imparare la Treccani a memoria... [F.d.A.] From michel a ziobudda.net Wed Nov 15 14:00:00 2006 From: michel a ziobudda.net (michel) Date: Wed Nov 15 14:06:02 2006 Subject: [Db] [mySQL] se non =?ISO-8859-15?Q?c=27=E8_crealo!?= In-Reply-To: <455B0294.1060900@pleiade.it> References: <1163538756.5327.37.camel@localhost> <455AC310.70802@pleiade.it> <455AD8A1.404@ziobudda.net> <455B0294.1060900@pleiade.it> Message-ID: <455B0F50.5040902@ziobudda.net> Domenico L. ha scritto: > Davide Michel 'ZioBudda' Morelli ha scritto: >> Domenico L. ha scritto: >>> >>> L'utilizzo dei campi numerici autoincrement come chiavi primarie è >>> un approccio ampiamente superato e che spesso da più problemi che >>> vantaggi. >> >> Ciao, spieghi meglio questo concetto ? > Lasciando perdere le polemiche che mi sembrano fuori luogo, ???? polemiche ??? Ti prego spiegami dove sta' la "polemica" nella mia semplice domanda. Se non era chiaro volevo sapere quali sono i problemi e i vantaggi ed il nuovo approccio. M. From ml a tassoman.com Wed Nov 15 14:12:39 2006 From: ml a tassoman.com (Tassoman (mailing)) Date: Wed Nov 15 14:18:29 2006 Subject: [Db] [mySQL] se non =?ISO-8859-1?Q?c'=E8?= crealo! In-Reply-To: <455AC310.70802@pleiade.it> References: <1163538756.5327.37.camel@localhost> <455AC310.70802@pleiade.it> Message-ID: <1163596359.5312.17.camel@localhost> Il giorno mer, 15/11/2006 alle 08.34 +0100, Domenico L. ha scritto: > in mysql ci sono 2 sintassi per fare insert o update in unica istruzione > dipende dalla versione, cmq è sempre meglio usare un'unica istruzione > piuttosto che 2 per vari motivi: > - la replace è atomica > - non devi scrivere codice php > - è più pulito > Problema: > - non è portabile, ma tanto neppure gli autoincrement lo sono quindi una > rimessa a posto la devi sempre fare e, per esempio, anche in oracle > esiste una funzione simile alla replace che si chiama merge, questo vuol > dire che in caso di migrazione devi cambiare un'isturzione sql e non il > codice. > > > L'utilizzo dei campi numerici autoincrement come chiavi primarie è un > approccio ampiamente superato e che spesso da più problemi che vantaggi. > > Se il campo nome è unique (e magari not null) perché non fai diventare > questo chiave primaria e butti via il campo id? > > Però bisogna fare attenzione ad essere certi che il campo nome sia > sempre unique e capire se deve esserlo case sensitive o meno (mario e > Mario sono la stessa chiave o no?) Fortunatamente la portabilità non è un problema, per ora. Trattandosi di un progetto personale, penso di affidarmi esclusivamente a mysql. Quindi credo che la REPLACE in questo caso possa essere cosa buona. I dati che vado a raccogliere, i nomi sono tutti maiuscoli. Al limite contengono spazi e ' che starebbero per accenti. Che siano unique devo ancora scoprirlo. Ma credo che per come sia strutturata la cosa debbano esserlo con ampia probabilità. La int auto increment pensavo di metterla come riferimento per le USING durante le query di JOIN, però effettivamente se solo il nome fa da chiave è già sufficiente, a patto di inserire lo stesso nome anche nelle altre tabelle. Alla fine però inserisco sto nome 2 volte e mi vien da pensare che di nuovo potrei avere problemi di lievitazione ? -- Blogging humanum est, Tassoman ovest. http://blog.tassoman.com From domenico.lorusso a pleiade.it Wed Nov 15 14:20:30 2006 From: domenico.lorusso a pleiade.it (Domenico L.) Date: Wed Nov 15 14:24:46 2006 Subject: [Db] [mySQL] se non =?ISO-8859-15?Q?c=27=E8_crealo!?= In-Reply-To: <455B0F50.5040902@ziobudda.net> References: <1163538756.5327.37.camel@localhost> <455AC310.70802@pleiade.it> <455AD8A1.404@ziobudda.net> <455B0294.1060900@pleiade.it> <455B0F50.5040902@ziobudda.net> Message-ID: <455B141E.3070903@pleiade.it> michel ha scritto: > ???? polemiche ??? > Ti prego spiegami dove sta' la "polemica" nella mia semplice domanda. no! no! non alla tua, ci mancherebbe! ho colto una nota polemica in alcune risposte successive, ma ho risposto globalmente e a te perché sei stato il primo In ogni caso anche per le risposte successive potrei essermi sbagliato... ripeto niente polemiche... da parte mia per primo, spero di essermi spiegato :-) -- Domenico L. icq: 645 44 861 per stupire mezz'ora basta un libro di storia, io cercai di imparare la Treccani a memoria... [F.d.A.] From cristiano a verondini.it Wed Nov 15 14:46:40 2006 From: cristiano a verondini.it (Cristiano Verondini) Date: Wed Nov 15 14:51:22 2006 Subject: =?UTF-8?Q?Re:_=5BDb=5D_=5BmySQL=5D_se_non_c_=C3=A8_crea?= =?UTF-8?Q?lo!?= References: <1163538756.5327.37.camel@localhost> <455AC310.70802@pleiade.it><018801c7089f$82092c50$6301a8c0@IdeaFutura.local> <455AF8F5.9090804@email.it> Message-ID: <002701c708bc$7f4a0620$6301a8c0@IdeaFutura.local> >>> Non mi risulta. L'utilizzo di chiavi surrogate ha una serie di >>> vantaggi, non ultimo quello delle performances durante i join. >> hai dei dati a supporto di questa affermazione? >> tempo fa avevo fatto due prova solo che non mi ricordo se ho >> conservato i risultati ... No, ma non dovrebbe essere difficile fare qualche test. Cris -- Cristiano Verondini http://www.verondini.it --- [ICQ: 114 190] From cristiano a verondini.it Wed Nov 15 14:51:21 2006 From: cristiano a verondini.it (Cristiano Verondini) Date: Wed Nov 15 14:56:06 2006 Subject: =?ISO-8859-15?Q?Re:_=5BDb=5D_=5BmySQL=5D_se_non_c'=E8_crealo!?= References: <1163538756.5327.37.camel@localhost> <455AC310.70802@pleiade.it><455AD8A1.404@ziobudda.net> <455B0294.1060900@pleiade.it> Message-ID: <003801c708bd$25a6ad70$6301a8c0@IdeaFutura.local> >> Se per me è chiave la sequenza di 12 caratteri che mi identifica >> regione-provincia-comune-filiale, suddiviso in 4 campi, se decido di >> portarmi appresso questi 4 campi nelle tabelle di dettaglio (quelle >> che >> per intenderci sono legate 1-n) >> >> quindi >> tabella padre: >> regione char(3) >> provincia char(3) >> comune char(3) >> filiale char(3) >> .... >> >> >> >> tabella figlo: >> regione char(3) >> provincia char(3) >> comune char(3) >> filiale char(3) >> .... >> >> >> Se voglio estrarre tutti i record (magari aggregati) dalla tabella >> figlio *non* devo fare una join ma una semplice where Questa non l'ho capita. E se nelle tabelle figlio mi porto dietro una chiave surrogata? Posso comunque continuare ad avere quei dati, magari anche indicizzati ... >> Terzo, se hai già una chiave (come il caso preso in oggetto) pensi >> che aggiungere un campo non faccia cmq levitare la base dati, >> sono cmq di solito levitazioni trascurabili, a questo punto val la >> pena chiedersi quanto è lungo il campo testuale e quanto spesso viene >> modificato (se viene modificato) Il punto è che un indice con chiave surrogata di solito occupa molto meno spazio di un indice con chiave naturale (o 'intelligent' come alcuni la definiscono). QUesto si traduce ovviamente in tempi di accesso notevolmente minori. >> l'implementazione che ho mostrato della tabella padre e figlio *è* >> in terza forma normale. Lo sarebbe anche usando chiavi surrogate, ovviamente omettendo i dati di relazione. Riassumendo, come sempre, la risposta è: 'dipende'! :)) Cris -- Cristiano Verondini http://www.verondini.it --- [ICQ: 114 190] From cristiano a verondini.it Wed Nov 15 14:52:15 2006 From: cristiano a verondini.it (Cristiano Verondini) Date: Wed Nov 15 14:56:54 2006 Subject: =?ISO-8859-15?Q?Re:_=5BDb=5D_=5BmySQL=5D_se_non_c'=E8_crealo!?= References: <1163538756.5327.37.camel@localhost><455AC310.70802@pleiade.it> <455AD8A1.404@ziobudda.net><455B0294.1060900@pleiade.it> <455B033D.8050509@pleiade.it> Message-ID: <004401c708bd$45a6d0f0$6301a8c0@IdeaFutura.local> >>> Se voglio estrarre tutti i record (magari aggregati) dalla tabella >>> figlio *non* devo fare una join ma una semplice where >> intendevo ovviamente tutti i record di un comune o di una provincia >> o di un regione :-) Questo vale quindi unicamente se fai una ricerca per un campo che appartiene alla chiave (e in mysql questo è efficiente solo se fa parte della *prima* parte della chiave). Cris -- Cristiano Verondini http://www.verondini.it --- [ICQ: 114 190] From domenico.lorusso a pleiade.it Wed Nov 15 15:26:44 2006 From: domenico.lorusso a pleiade.it (Domenico L.) Date: Wed Nov 15 15:31:14 2006 Subject: [Db] [mySQL] se non =?ISO-8859-15?Q?c=27=E8_crealo!?= In-Reply-To: <004401c708bd$45a6d0f0$6301a8c0@IdeaFutura.local> References: <1163538756.5327.37.camel@localhost><455AC310.70802@pleiade.it> <455AD8A1.404@ziobudda.net><455B0294.1060900@pleiade.it> <455B033D.8050509@pleiade.it> <004401c708bd$45a6d0f0$6301a8c0@IdeaFutura.local> Message-ID: <455B23A4.9090306@pleiade.it> Cristiano Verondini ha scritto: >>>> Se voglio estrarre tutti i record (magari aggregati) dalla tabella >>>> figlio *non* devo fare una join ma una semplice where > >>> intendevo ovviamente tutti i record di un comune o di una provincia >>> o di un regione :-) > > Questo vale quindi unicamente se fai una ricerca per un campo che > appartiene alla chiave (e in mysql questo è efficiente solo se fa > parte della *prima* parte della chiave). > l'efficenza la danno gli indici la mia osservazione era indipendente: mi riferivo al fatto che non ti serviva fare una join sulla tabella padre. Il fatto che cmq tutto dipende da cosa vuoi ottenere è sempre molto vero, ma è anche vero che nelle basi dati dovrebbe essere un problema minore quello della dimensione rispetto alla gestibilità ciao -- Domenico L. icq: 645 44 861 per stupire mezz'ora basta un libro di storia, io cercai di imparare la Treccani a memoria... [F.d.A.] From angelo.galleja a email.it Wed Nov 15 16:39:18 2006 From: angelo.galleja a email.it (Angelo Galleja) Date: Wed Nov 15 16:45:01 2006 Subject: [Db] [mySQL] se non c =?ISO-8859-1?Q?=E8_crealo!?= In-Reply-To: References: <1163538756.5327.37.camel@localhost> <455AC310.70802@pleiade.it> <018801c7089f$82092c50$6301a8c0@IdeaFutura.local> <455AF8F5.9090804@email.it> Message-ID: <455B34A6.5020009@email.it> Matteo Giacomazzi ha scritto: > 2006/11/15, Angelo Galleja : >> >> > Non mi risulta. L'utilizzo di chiavi surrogate ha una serie di >> > vantaggi, non ultimo quello delle performances durante i join. >> >> hai dei dati a supporto di questa affermazione? >> tempo fa avevo fatto due prova solo che non mi ricordo se ho >> conservato >> i risultati ... > > > > Stai chiedendo se ci sono dati a supporto del fatto che un confronto tra > interi è più performante di un confronto tra altri tipi di dato (e.g. > stringhe)? > no, sto chiedendo se ci sono dati a supporto del fatto che una join sia più performante con chiavi numeriche piuttosto che con altri tipi di dato (e.g stringhe) in ogni caso rimango convinto che: - una primary key deve avere una corrispondenza nella realtà, quindi evitare id numerici sempre e comunque, salvo eccezioni ovviamente :) - l'eventuale vantaggio ottenuto dall'utilizzo di pk numeriche sia trascurabile se il prezzo da pagare è la mancata corrispondenza di cui sopra spero tu non abbia idea di quello che si trova in giro :), recentemente ho chiesto delucidazioni all'autore di un noto software di settore (ometto volutamente sia il nome software, che del settore) dato che dovevo creare dei report a partire dalle tabelle di questo "coso", dopo aver letto la prima email in cui mi indicava le "join"[1] da effettuare per ricavare dati incrociati da tre tabelle ho pensato _seriamente_ di abbandonare [1] alcune veramente illuminanti dal punto di vista didattico del tipo i "primi tre caratteri del campo" From cristiano a verondini.it Wed Nov 15 16:43:28 2006 From: cristiano a verondini.it (Cristiano Verondini) Date: Wed Nov 15 16:48:17 2006 Subject: =?iso-8859-1?Q?Re:_=5BDb=5D_=5BmySQL=5D_se_non_c_=E8_crealo!?= References: <1163538756.5327.37.camel@localhost><455AC310.70802@pleiade.it> <018801c7089f$82092c50$6301a8c0@IdeaFutura.local> <455AF8F5.9090804@email.it> <455B34A6.5020009@email.it> Message-ID: <009c01c708cc$cf416af0$6301a8c0@IdeaFutura.local> > no, sto chiedendo se ci sono dati a supporto del fatto che una join > sia più performante con chiavi numeriche piuttosto che con altri tipi di > dato (e.g > stringhe) Bhe, questo mi sembra evidente, se non altro per gli acessi ad indice. > - una primary key deve avere una corrispondenza nella realtà, > quindi evitare id numerici sempre e comunque, salvo eccezioni > ovviamente :) - l'eventuale vantaggio ottenuto dall'utilizzo di pk > numeriche sia trascurabile se il prezzo da pagare è la mancata > corrispondenza di cui sopra Sinceramente non vedo il motivo di creare una 'relazione' fra una PK e la realtà, ma de gustibus ... :) Qui c'è comunque un articolo che elenca un po' di pro e contro: http://www.bcarter.com/intsurr1.htm Cris -- Cristiano Verondini http://www.verondini.it --- [ICQ: 114 190] From angelo.galleja a email.it Wed Nov 15 16:52:16 2006 From: angelo.galleja a email.it (Angelo Galleja) Date: Wed Nov 15 16:58:09 2006 Subject: [Db] [mySQL] se non c =?ISO-8859-15?Q?=E8_crealo!?= In-Reply-To: <003801c708bd$25a6ad70$6301a8c0@IdeaFutura.local> References: <1163538756.5327.37.camel@localhost> <455AC310.70802@pleiade.it><455AD8A1.404@ziobudda.net> <455B0294.1060900@pleiade.it> <003801c708bd$25a6ad70$6301a8c0@IdeaFutura.local> Message-ID: <455B37B0.8020302@email.it> Cristiano Verondini ha scritto: > >>> Se per me è chiave la sequenza di 12 caratteri che mi identifica >>> regione-provincia-comune-filiale, suddiviso in 4 campi, se decido di >>> portarmi appresso questi 4 campi nelle tabelle di dettaglio (quelle >>> che >>> per intenderci sono legate 1-n) >>> >>> quindi >>> tabella padre: >>> regione char(3) >>> provincia char(3) >>> comune char(3) >>> filiale char(3) >>> .... >>> >>> >>> >>> tabella figlo: >>> regione char(3) >>> provincia char(3) >>> comune char(3) >>> filiale char(3) >>> .... >>> >>> >>> Se voglio estrarre tutti i record (magari aggregati) dalla tabella >>> figlio *non* devo fare una join ma una semplice where > > Questa non l'ho capita. E se nelle tabelle figlio mi porto dietro una > chiave surrogata? Posso comunque continuare ad avere quei dati, magari > anche indicizzati ... invece di fare SELECT .... FROM padre ... LEFT JOIN ON figlio.idpadre=padre.id... WHERE padre.regione = '...' etc. etc. fai SELECT .. FROM figlio WHERE regione=... etc. etc. ti risparmi una join, considera il caso in cui la tabella padre dovesse andare perduta (estremizzo volutamente), la tabella figlio avrebbe ancora un significato logico perchè i campi che compongono la pk hanno una corrispondenza nella realtà. From cristiano a verondini.it Wed Nov 15 17:00:09 2006 From: cristiano a verondini.it (Cristiano Verondini) Date: Wed Nov 15 17:04:51 2006 Subject: =?ISO-8859-15?Q?Re:_=5BDb=5D_=5BmySQL=5D_se_non_c_=E8_crealo!?= References: <1163538756.5327.37.camel@localhost> <455AC310.70802@pleiade.it><455AD8A1.404@ziobudda.net> <455B0294.1060900@pleiade.it><003801c708bd$25a6ad70$6301a8c0@IdeaFutura.local> <455B37B0.8020302@email.it> Message-ID: <00d001c708cf$241a62f0$6301a8c0@IdeaFutura.local> >> fai SELECT .. FROM figlio WHERE regione=... etc. etc. >> >> ti risparmi una join, considera il caso in cui la tabella padre >> dovesse andare perduta (estremizzo volutamente), la tabella figlio >> avrebbe ancora un significato logico perchè i campi che compongono >> la pk hanno una corrispondenza nella realtà. Lo trovo un esempio poco calzante. Primo perchè non deve succedere che si cancella una tabella (e certo non decido la *struttura* del DB in vista di un evento di questo tipo), secondo perché la ricerca che fai nella tabella figlio di per sé ha poco significato, probabilmente dovrai risalire all'elemento padre dei record trovato (e vai di join). Oltretutto, la WHERE andrebbe fatta con valori per campi componenti l'indice nella sua parte iniziale ... insomma, lo trovo poco pratico. Cris -- Cristiano Verondini http://www.verondini.it --- [ICQ: 114 190] From angelo.galleja a email.it Wed Nov 15 17:00:48 2006 From: angelo.galleja a email.it (Angelo Galleja) Date: Wed Nov 15 17:06:45 2006 Subject: [Db] [mySQL] se non c =?ISO-8859-1?Q?=E8_crealo!?= In-Reply-To: <009c01c708cc$cf416af0$6301a8c0@IdeaFutura.local> References: <1163538756.5327.37.camel@localhost><455AC310.70802@pleiade.it> <018801c7089f$82092c50$6301a8c0@IdeaFutura.local> <455AF8F5.9090804@email.it> <455B34A6.5020009@email.it> <009c01c708cc$cf416af0$6301a8c0@IdeaFutura.local> Message-ID: <455B39B0.8090308@email.it> Cristiano Verondini ha scritto: >> no, sto chiedendo se ci sono dati a supporto del fatto che una join >> sia più performante con chiavi numeriche piuttosto che con >> altri tipi di dato (e.g stringhe) > > Bhe, questo mi sembra evidente, se non altro per gli acessi ad indice. mi è rimasta una parola sulla tastiera :) intendevo "chiavi non numeriche" > >> - una primary key deve avere una corrispondenza nella realtà, >> quindi evitare id numerici sempre e comunque, salvo eccezioni >> ovviamente :) - l'eventuale vantaggio ottenuto dall'utilizzo di pk >> numeriche sia trascurabile se il prezzo da pagare è la mancata >> corrispondenza di cui sopra > > Sinceramente non vedo il motivo di creare una 'relazione' fra una PK > e la realtà, ma de gustibus ... :) vedi risposta all'altro tuo post, > Qui c'è comunque un articolo che elenca un po' di pro e contro: > http://www.bcarter.com/intsurr1.htm "The biggest disadvantage for intelligent keys, and a corresponding advantage for surrogate keys, is that primary keys are hard to change. Whenever a primary key changes in value, or columns are added to or dropped from a primary key, the effects cascade down through foreign key relationships. Intelligent keys suffer from this problem because not only are they used as primary and foreign keys but they also have some business meaning associated with them. When the business changes, so do the primary key values or structure, with all the problems associated with such a change. questo non è assolutamente uno svantaggio ed è palese: la realtà cambia -> i dati che rappresentano la realtà cambiano From ml a tassoman.com Wed Nov 15 17:01:21 2006 From: ml a tassoman.com (Tassoman (mailing)) Date: Wed Nov 15 17:07:06 2006 Subject: [Db] [mySQL] se non =?ISO-8859-1?Q?c'=E8?= crealo! In-Reply-To: <455B23A4.9090306@pleiade.it> References: <1163538756.5327.37.camel@localhost><455AC310.70802@pleiade.it> <455AD8A1.404@ziobudda.net><455B0294.1060900@pleiade.it> <455B033D.8050509@pleiade.it> <004401c708bd$45a6d0f0$6301a8c0@IdeaFutura.local> <455B23A4.9090306@pleiade.it> Message-ID: <1163606482.5312.22.camel@localhost> Il giorno mer, 15/11/2006 alle 15.26 +0100, Domenico L. ha scritto: > Il fatto che cmq tutto dipende da cosa vuoi ottenere è sempre molto > vero, ma è anche vero che nelle basi dati dovrebbe essere un problema > minore quello della dimensione rispetto alla gestibilità In effetti in qualsiasi caso ha più senso preoccuparsi delle performance piuttosto che dell'infrastruttura, nel caso in cui le performance dell'applicazione sono ottimali, l'audience ottenuto permetterebbe di sicuro un aggiornamento dell'infrastruttura. -- Blogging humanum est, Tassoman ovest. http://blog.tassoman.com From cristiano a verondini.it Wed Nov 15 17:05:52 2006 From: cristiano a verondini.it (Cristiano Verondini) Date: Wed Nov 15 17:10:33 2006 Subject: =?iso-8859-1?Q?Re:_=5BDb=5D_=5BmySQL=5D_se_non_c_=E8_crealo!?= References: <1163538756.5327.37.camel@localhost><455AC310.70802@pleiade.it> <018801c7089f$82092c50$6301a8c0@IdeaFutura.local> <455AF8F5.9090804@email.it> <455B34A6.5020009@email.it><009c01c708cc$cf416af0$6301a8c0@IdeaFutura.local> <455B39B0.8090308@email.it> Message-ID: <00e101c708cf$f020c380$6301a8c0@IdeaFutura.local> > "The biggest disadvantage for intelligent keys, and a corresponding > advantage for surrogate keys, is that primary keys are hard to change. > Whenever a primary key changes in value, or columns are added to or > dropped from a primary key, the effects cascade down through foreign > key relationships. > Intelligent keys suffer from this problem because not only are they > used as primary and foreign keys but they also have some business > meaning associated with them. When the business changes, so do the primary > key values or structure, > with all the problems associated with such a change. > > questo non è assolutamente uno svantaggio ed è palese: > la realtà cambia -> i dati che rappresentano la realtà cambiano Quello che intende è che se la realtà cambia e le tue relazioni sono basate su un dato che cambia, gestire il cambiamento è, tecnicamente parlando, pain in the ass! :) Cris -- Cristiano Verondini http://www.verondini.it --- [ICQ: 114 190] From domenico.lorusso a pleiade.it Wed Nov 15 17:08:56 2006 From: domenico.lorusso a pleiade.it (Domenico L.) Date: Wed Nov 15 17:13:13 2006 Subject: [Db] [mySQL] se non c =?ISO-8859-15?Q?=E8_crealo!?= In-Reply-To: <00d001c708cf$241a62f0$6301a8c0@IdeaFutura.local> References: <1163538756.5327.37.camel@localhost> <455AC310.70802@pleiade.it><455AD8A1.404@ziobudda.net> <455B0294.1060900@pleiade.it><003801c708bd$25a6ad70$6301a8c0@IdeaFutura.local> <455B37B0.8020302@email.it> <00d001c708cf$241a62f0$6301a8c0@IdeaFutura.local> Message-ID: <455B3B98.80805@pleiade.it> Cristiano Verondini ha scritto: >>> fai SELECT .. FROM figlio WHERE regione=... etc. etc. >>> >>> ti risparmi una join, considera il caso in cui la tabella padre >>> dovesse andare perduta (estremizzo volutamente), la tabella figlio >>> avrebbe ancora un significato logico perchè i campi che compongono >>> la pk hanno una corrispondenza nella realtà. > > Lo trovo un esempio poco calzante. Primo perchè non deve succedere > che si cancella una tabella (e certo non decido la *struttura* del DB > in vista di un evento di questo tipo), secondo perché la ricerca che > fai nella tabella figlio di per sé ha poco significato, probabilmente > dovrai risalire all'elemento padre dei record trovato (e vai di join). > Oltretutto, la WHERE andrebbe fatta con valori per campi componenti > l'indice nella sua parte iniziale ... insomma, lo trovo poco pratico. Mah.... dunque l'esempio che ho portato non era compiutamente astratto, ma si basava su un progetto serio, avere una chiave intelligente più della metà delle volte mi evitava join. Attenzione! spesso le tabelle padre avevano una chiave numerica di tipo autoincrement perché non c'erano altre chiavi primarie! :-) Però se ci sono tre tabelle nonno->padre->figlio facevo in modo che figlio avesse come chiavi sia il codice del nonno che del padre (es.: regione-provincia-comune) Un'altra osservazione che vale la pena fare è che se Esiste una gerarchia nella chiave, questa è informazione che conviene tenere, e quindi è meglio avere chiavi con più campi. Sugli indici, invece trovo che l'osservazione sia fuori luogo, gli indici si mettono dove servono, poi da rdbms a rdbms ci sono politiche diverse e quindi non ha senso parlare di vantaggi e svantaggi in senso assoluto. Inoltre converrai con me che ha poco senso fare un raggruppamento sul codice provincia 001 che è sempre il capoluogo di una regione, questo per dire che i raggruppamenti sfruttano quasi sempre la gerarchia -- Domenico L. icq: 645 44 861 per stupire mezz'ora basta un libro di storia, io cercai di imparare la Treccani a memoria... [F.d.A.] From cristiano a verondini.it Wed Nov 15 17:13:19 2006 From: cristiano a verondini.it (Cristiano Verondini) Date: Wed Nov 15 17:18:00 2006 Subject: =?ISO-8859-15?Q?Re:_=5BDb=5D_=5BmySQL=5D_se_non_c_=E8_crealo!?= References: <1163538756.5327.37.camel@localhost> <455AC310.70802@pleiade.it><455AD8A1.404@ziobudda.net> <455B0294.1060900@pleiade.it><003801c708bd$25a6ad70$6301a8c0@IdeaFutura.local> <455B37B0.8020302@email.it><00d001c708cf$241a62f0$6301a8c0@IdeaFutura.local> <455B3B98.80805@pleiade.it> Message-ID: <00ed01c708d0$fab5b2a0$6301a8c0@IdeaFutura.local> >> Inoltre converrai con me che ha poco senso fare un raggruppamento sul >> codice provincia 001 che è sempre il capoluogo di una regione, questo >> per dire che i raggruppamenti sfruttano quasi sempre la gerarchia Ha senso creare indici se la selettività è alta. Se è bassa, lo stesso motore db non lo sua! :) Cris -- Cristiano Verondini http://www.verondini.it --- [ICQ: 114 190] From angelo.galleja a email.it Wed Nov 15 17:15:23 2006 From: angelo.galleja a email.it (Angelo Galleja) Date: Wed Nov 15 17:21:03 2006 Subject: [Db] [mySQL] se non c =?ISO-8859-15?Q?=E8_crealo!?= In-Reply-To: <00d001c708cf$241a62f0$6301a8c0@IdeaFutura.local> References: <1163538756.5327.37.camel@localhost> <455AC310.70802@pleiade.it><455AD8A1.404@ziobudda.net> <455B0294.1060900@pleiade.it><003801c708bd$25a6ad70$6301a8c0@IdeaFutura.local> <455B37B0.8020302@email.it> <00d001c708cf$241a62f0$6301a8c0@IdeaFutura.local> Message-ID: <455B3D1B.5050208@email.it> Cristiano Verondini ha scritto: >>> fai SELECT .. FROM figlio WHERE regione=... etc. etc. >>> >>> ti risparmi una join, considera il caso in cui la tabella padre >>> dovesse andare perduta (estremizzo volutamente), la tabella figlio >>> avrebbe ancora un significato logico perchè i campi che compongono >>> la pk hanno una corrispondenza nella realtà. > > Lo trovo un esempio poco calzante. Primo perchè non deve succedere > che si cancella una tabella (e certo non decido la *struttura* del DB in > vista di un evento di questo tipo), ho estremizzato volutamente :) c'era anche scritto tra parentesi > secondo perché la ricerca che fai > nella tabella figlio di per sé ha poco significato perchè? sto cercando qualcosa che ha una corrispondenza nella realtà: sto cercando "nonsocosa" che sia in LIGURIA->GENOVA->GE->LA_MIA_FILIALE e IMHO è più naturale di cercare "nonsocosa" che abbia come id padre 26 >, probabilmente dovrai > risalire all'elemento padre dei record trovato (e vai di join). probabilmente, ma qualora non fosse così mi sono risparmiato una JOIN > Oltretutto, la WHERE andrebbe fatta con valori per campi componenti > l'indice nella sua parte iniziale ... scusa ma questa parte non l'ho capita >insomma, lo trovo poco pratico. non credo sia solo questione di praticità From cristiano a verondini.it Wed Nov 15 17:20:26 2006 From: cristiano a verondini.it (Cristiano Verondini) Date: Wed Nov 15 17:25:06 2006 Subject: =?ISO-8859-15?Q?Re:_=5BDb=5D_=5BmySQL=5D_se_non_c_=E8_crealo!?= References: <1163538756.5327.37.camel@localhost> <455AC310.70802@pleiade.it><455AD8A1.404@ziobudda.net> <455B0294.1060900@pleiade.it><003801c708bd$25a6ad70$6301a8c0@IdeaFutura.local> <455B37B0.8020302@email.it><00d001c708cf$241a62f0$6301a8c0@IdeaFutura.local> <455B3D1B.5050208@email.it> Message-ID: <00fe01c708d1$f90b6890$6301a8c0@IdeaFutura.local> >> sto cercando "nonsocosa" che sia in >> LIGURIA->GENOVA->GE->LA_MIA_FILIALE e IMHO è più naturale di cercare >> "nonsocosa" che abbia come id padre 26 Ma per sapere cos'è quel 'nonsocosa' devi risalire al padre. >>> , probabilmente dovrai >>> risalire all'elemento padre dei record trovato (e vai di join). >> >> probabilmente, ma qualora non fosse così mi sono risparmiato una JOIN Ecco. In quanti casi hai la necessità di conoscere *solo* i figli senza sapere di che padre sono? (mater semper certa est, pater ... ;) ) >>> Oltretutto, la WHERE andrebbe fatta con valori per campi componenti >>> l'indice nella sua parte iniziale ... >> >> scusa ma questa parte non l'ho capita Se ho un indice composto da, diciamo, tre campi, a, b, c le WHERE, per poter usare l'indice, devono essere: (1) WHERE a = '...' (2) WHERE a = '...' AND b = '...' (3) WHERE a = '...' AND b = '...' AND c = '...' Altrimenti l'indice non può essere usato. Dovrebbe essere una limitazione dei BTree, quindi sicuramente MySQL ne soffre. Per altri motori, non saprei. Cris -- Cristiano Verondini http://www.verondini.it --- [ICQ: 114 190] From angelo.galleja a email.it Wed Nov 15 17:20:31 2006 From: angelo.galleja a email.it (Angelo Galleja) Date: Wed Nov 15 17:26:18 2006 Subject: [Db] [mySQL] se non c =?ISO-8859-1?Q?=E8_crealo!?= In-Reply-To: <00e101c708cf$f020c380$6301a8c0@IdeaFutura.local> References: <1163538756.5327.37.camel@localhost><455AC310.70802@pleiade.it> <018801c7089f$82092c50$6301a8c0@IdeaFutura.local> <455AF8F5.9090804@email.it> <455B34A6.5020009@email.it><009c01c708cc$cf416af0$6301a8c0@IdeaFutura.local> <455B39B0.8090308@email.it> <00e101c708cf$f020c380$6301a8c0@IdeaFutura.local> Message-ID: <455B3E4F.3010904@email.it> Cristiano Verondini ha scritto: > >> "The biggest disadvantage for intelligent keys, and a corresponding >> advantage for surrogate keys, is that primary keys are hard to change. >> Whenever a primary key changes in value, or columns are added to or >> dropped from a primary key, the effects cascade down through foreign >> key relationships. >> Intelligent keys suffer from this problem because not only are they >> used as primary and foreign keys but they also have some business >> meaning associated with them. When the business changes, so do the >> primary key values or structure, >> with all the problems associated with such a change. >> >> questo non è assolutamente uno svantaggio ed è palese: >> la realtà cambia -> i dati che rappresentano la realtà cambiano > > Quello che intende è che se la realtà cambia e le tue relazioni sono > basate su un dato che cambia, gestire il cambiamento è, tecnicamente > parlando, pain in the ass! :) e perchè? anche senza l'aiuto del database si risolve con un paio di update ... non vedo il problema vuoi mettere avere dei dati che rispecchiano la realtà? From cristiano a verondini.it Wed Nov 15 17:24:38 2006 From: cristiano a verondini.it (Cristiano Verondini) Date: Wed Nov 15 17:29:20 2006 Subject: =?iso-8859-1?Q?Re:_=5BDb=5D_=5BmySQL=5D_se_non_c_=E8_crealo!?= References: <1163538756.5327.37.camel@localhost><455AC310.70802@pleiade.it> <018801c7089f$82092c50$6301a8c0@IdeaFutura.local> <455AF8F5.9090804@email.it> <455B34A6.5020009@email.it><009c01c708cc$cf416af0$6301a8c0@IdeaFutura.local> <455B39B0.8090308@email.it><00e101c708cf$f020c380$6301a8c0@IdeaFutura.local> <455B3E4F.3010904@email.it> Message-ID: <010601c708d2$8f9094c0$6301a8c0@IdeaFutura.local> >> Quello che intende è che se la realtà cambia e le tue relazioni >> sono basate su un dato che cambia, gestire il cambiamento è, >> tecnicamente parlando, pain in the ass! :) > > e perchè? anche senza l'aiuto del database si risolve con un paio > di update ... non vedo il problema Usando chiavi surrogate, non devi neanche aggiornare le relazioni! :) > vuoi mettere avere dei dati che rispecchiano la realtà? I *dati* continuano a rispecchiare la realtà, cambia il modo di organizzare (o rappresentare) le relazioni. Ad ogni modo, io preferisco usare chiavi surrogate, e non ho mai avuto alcun problema (se non divertirmi a scrivere JOIN 'complesse'). Non voglio sostenere che sia la soluzione migliore, non credo che ne esista una migliore in assoluto, ma grazie all'uso di chiavi surrogate non ho mai avuto problemi, e questo mi basta! :) Cris -- Cristiano Verondini http://www.verondini.it --- [ICQ: 114 190] From marcello a vezz.it Wed Nov 15 17:27:20 2006 From: marcello a vezz.it (Marcello Vezzelli) Date: Wed Nov 15 17:33:02 2006 Subject: [Db] [mySQL] se non c =?ISO-8859-1?Q?=E8_crealo!?= In-Reply-To: <010601c708d2$8f9094c0$6301a8c0@IdeaFutura.local> References: <1163538756.5327.37.camel@localhost><455AC310.70802@pleiade.it> <018801c7089f$82092c50$6301a8c0@IdeaFutura.local> <455AF8F5.9090804@email.it> <455B34A6.5020009@email.it><009c01c708cc$cf416af0$6301a8c0@IdeaFutura.local> <455B39B0.8090308@email.it><00e101c708cf$f020c380$6301a8c0@IdeaFutura.local> <455B3E4F.3010904@email.it> <010601c708d2$8f9094c0$6301a8c0@IdeaFutura.local> Message-ID: <455B3FE8.8000004@vezz.it> Cristiano Verondini ha scritto: > > Ad ogni modo, io preferisco usare chiavi surrogate, e non ho mai > avuto alcun problema (se non divertirmi a scrivere JOIN 'complesse'). > Non voglio sostenere che sia la soluzione migliore, non credo che ne > esista una migliore in assoluto, ma grazie all'uso di chiavi surrogate > non ho mai avuto problemi, e questo mi basta! :) Concordo 100%. Un bell'intero autoincrementante come primo campo di record in chiave primaria mi fa dormire tranquillo :) Pago volentieri il prezzo di dover scrivere una join un po' più complicata o meno leggibile. Saluti Marcello From angelo.galleja a email.it Wed Nov 15 17:34:52 2006 From: angelo.galleja a email.it (Angelo Galleja) Date: Wed Nov 15 17:40:41 2006 Subject: [Db] [mySQL] se non c =?ISO-8859-15?Q?=E8_crealo!?= In-Reply-To: <00fe01c708d1$f90b6890$6301a8c0@IdeaFutura.local> References: <1163538756.5327.37.camel@localhost> <455AC310.70802@pleiade.it><455AD8A1.404@ziobudda.net> <455B0294.1060900@pleiade.it><003801c708bd$25a6ad70$6301a8c0@IdeaFutura.local> <455B37B0.8020302@email.it><00d001c708cf$241a62f0$6301a8c0@IdeaFutura.local> <455B3D1B.5050208@email.it> <00fe01c708d1$f90b6890$6301a8c0@IdeaFutura.local> Message-ID: <455B41AC.3000101@email.it> Cristiano Verondini ha scritto: >>> sto cercando "nonsocosa" che sia in >>> LIGURIA->GENOVA->GE->LA_MIA_FILIALE e IMHO è più naturale di cercare >>> "nonsocosa" che abbia come id padre 26 > > Ma per sapere cos'è quel 'nonsocosa' devi risalire al padre. non necessariamente, finora in tutti i software che ho sviluppato mi sono sempre trovato bene con questo approccio >>>> , probabilmente dovrai >>>> risalire all'elemento padre dei record trovato (e vai di join). >>> >>> probabilmente, ma qualora non fosse così mi sono risparmiato una JOIN > > Ecco. In quanti casi hai la necessità di conoscere *solo* i figli > senza sapere di che padre sono? (mater semper certa est, pater ... ;) ) "più di quanti tu possa immaginare" (semicit.) :) a parte gli scherzi mi è capitato più di una volta > >>>> Oltretutto, la WHERE andrebbe fatta con valori per campi componenti >>>> l'indice nella sua parte iniziale ... >>> >>> scusa ma questa parte non l'ho capita > > Se ho un indice composto da, diciamo, tre campi, a, b, c le WHERE, > per poter usare l'indice, devono essere: > > (1) WHERE a = '...' > (2) WHERE a = '...' AND b = '...' > (3) WHERE a = '...' AND b = '...' AND c = '...' > > Altrimenti l'indice non può essere usato. impostando tutto in un certo modo userai sempre il WHERE con tutti i campi che compongono la chiave perchè la chiave è quella > Dovrebbe essere una > limitazione dei BTree, quindi sicuramente MySQL ne soffre. Per altri > motori, non saprei. grazie per la spiegazione From angelo.galleja a email.it Wed Nov 15 17:39:55 2006 From: angelo.galleja a email.it (Angelo Galleja) Date: Wed Nov 15 17:45:35 2006 Subject: [Db] [mySQL] se non c =?ISO-8859-1?Q?=E8_crealo!?= In-Reply-To: <010601c708d2$8f9094c0$6301a8c0@IdeaFutura.local> References: <1163538756.5327.37.camel@localhost><455AC310.70802@pleiade.it> <018801c7089f$82092c50$6301a8c0@IdeaFutura.local> <455AF8F5.9090804@email.it> <455B34A6.5020009@email.it><009c01c708cc$cf416af0$6301a8c0@IdeaFutura.local> <455B39B0.8090308@email.it><00e101c708cf$f020c380$6301a8c0@IdeaFutura.local> <455B3E4F.3010904@email.it> <010601c708d2$8f9094c0$6301a8c0@IdeaFutura.local> Message-ID: <455B42DB.6080304@email.it> Cristiano Verondini ha scritto: >>> Quello che intende è che se la realtà cambia e le tue relazioni >>> sono basate su un dato che cambia, gestire il cambiamento è, >>> tecnicamente parlando, pain in the ass! :) >> >> e perchè? anche senza l'aiuto del database si risolve con un paio >> di update ... non vedo il problema > > Usando chiavi surrogate, non devi neanche aggiornare le relazioni! :) >> vuoi mettere avere dei dati che rispecchiano la realtà? > > I *dati* continuano a rispecchiare la realtà, cambia il modo di > organizzare (o rappresentare) le relazioni. aggiungendo un "qualcosa" che non ha niente a che fare con la realtà overro l'id > > Ad ogni modo, io preferisco usare chiavi surrogate, e non ho mai > avuto alcun problema (se non divertirmi a scrivere JOIN 'complesse'). > Non voglio sostenere che sia la soluzione migliore, non credo che ne > esista una migliore in assoluto, ma grazie all'uso di chiavi surrogate > non ho mai avuto problemi, e questo mi basta! :) poichè io preferisco usare chiavi naturali e che anch'io non ho mai avuto problemi deduco che potremmo parlarne all'infinito ... :) la mia aspettativa di vita dovrebbe essere sui 60-70 anni ... speriamo bastino :p cmq ancora una volta complimenti e grazie a ziobudda, questa mailing list diventa sempre più interessante From ml a tassoman.com Wed Nov 15 18:13:43 2006 From: ml a tassoman.com (Tassoman (mailing)) Date: Wed Nov 15 18:19:28 2006 Subject: [Db] [mySQL] se non c =?ISO-8859-1?Q?=E8?= crealo! In-Reply-To: <455B42DB.6080304@email.it> References: <1163538756.5327.37.camel@localhost><455AC310.70802@pleiade.it> <018801c7089f$82092c50$6301a8c0@IdeaFutura.local> <455AF8F5.9090804@email.it> <455B34A6.5020009@email.it> <009c01c708cc$cf416af0$6301a8c0@IdeaFutura.local> <455B39B0.8090308@email.it> <00e101c708cf$f020c380$6301a8c0@IdeaFutura.local> <455B3E4F.3010904@email.it> <010601c708d2$8f9094c0$6301a8c0@IdeaFutura.local> <455B42DB.6080304@email.it> Message-ID: <1163610823.5312.29.camel@localhost> Il giorno mer, 15/11/2006 alle 17.39 +0100, Angelo Galleja ha scritto: > poichè io preferisco usare chiavi naturali e che anch'io non ho mai avuto > problemi deduco che potremmo parlarne all'infinito ... :) > la mia aspettativa di vita dovrebbe essere sui 60-70 anni ... speriamo bastino :p > > cmq ancora una volta complimenti e grazie a ziobudda, questa mailing list diventa sempre più > interessante Bene quindi concludendo, adesso so che mi piacciono le chiavi surrogate e sono più in pace con me stesso. In pratica, W l'astrattismo. -- Blogging humanum est, Tassoman ovest. http://blog.tassoman.com From simone a tomato.it Thu Nov 16 10:05:36 2006 From: simone a tomato.it (Simone Fumagalli) Date: Thu Nov 16 10:10:49 2006 Subject: [Db] Caratteri non standard in DB oracle Message-ID: <455C29E0.1010802@tomato.it> Come suggeritomi da qualcuno sposto la discussione dalla lista PHP a quella DB :) La domanda è : Ho un DB Oracle che provviene da una vecchia applicazione. Nel DB c'è una tabella con un campo testo che contiene dei caratteri non standard: apici inversi singoli e doppi, triplo punto etc. (quelli di MS word per intenderci). In tutte le prove che ho fatto non riesco a leggere questi caratteri correttamente. Mi viene sempre ritornato il punto di domanda rovesciato al posto del carattere. Qualcuno ha idea di quali impostazioni (charset o altro) devo impostare? Oracle (versione 9.2) è su una macchina Windows2000 Server. La chiave local machine -> software - > oracle-> home0 ->nls_lang del registro è impostata a : ITALIAN_ITALY.WE8MSWIN1252 I dati li vado a leggere con un programmino Java che gira su una macchina Linux e li devo inserire in un DB MySQL in cui posso impostare charset/encoding che voglio. Se qualcuno ha idee Grazie Simone From domenico.lorusso a pleiade.it Thu Nov 16 10:20:46 2006 From: domenico.lorusso a pleiade.it (Domenico Lorusso) Date: Thu Nov 16 10:25:08 2006 Subject: [Db] Caratteri non standard in DB oracle In-Reply-To: <455C29E0.1010802@tomato.it> References: <455C29E0.1010802@tomato.it> Message-ID: <455C2D6E.6090101@pleiade.it> Simone Fumagalli ha scritto: > Oracle (versione 9.2) è su una macchina Windows2000 Server. La chiave > local machine -> software - > oracle-> home0 ->nls_lang del registro > è impostata a : ITALIAN_ITALY.WE8MSWIN1252 Allora fai le cose per passi: Sul client che charset è impostato? potrebbe bastarti : export NLS_LANG=ITALIAN_ITALY.WE8MSWIN1252 prima di lanciare i dati. Detto questo c'è il problema di conversione in mysql.... > > I dati li vado a leggere con un programmino Java che gira su una > macchina Linux e li devo inserire in un DB MySQL in cui posso > impostare charset/encoding che voglio. > > Se qualcuno ha idee > > Grazie > > Simone > _______________________________________________ > Db mailing list > Db@lists.ziobudda.net > http://lists.ziobudda.net/mailman/listinfo/db > > -- dr. Domenico Lorusso -->> Pleiade S.r.l. Via G. Romano, 29 Milano -->> Tel.: +39 02 584 30 542 From domenico.lorusso a pleiade.it Thu Nov 16 10:22:50 2006 From: domenico.lorusso a pleiade.it (Domenico L.) Date: Thu Nov 16 10:27:13 2006 Subject: [Db] Caratteri non standard in DB oracle In-Reply-To: <455C29E0.1010802@tomato.it> References: <455C29E0.1010802@tomato.it> Message-ID: <455C2DEA.9050307@pleiade.it> Scusate le mail di prima sono partite per sbaglio Simone Fumagalli ha scritto: > Oracle (versione 9.2) è su una macchina Windows2000 Server. La chiave > local machine -> software - > oracle-> home0 ->nls_lang del registro > è impostata a : ITALIAN_ITALY.WE8MSWIN1252 Allora fai le cose per passi: Sul client che charset è impostato? potrebbe bastarti : export NLS_LANG=ITALIAN_ITALY.WE8MSWIN1252 prima di lanciare il programmino. Detto questo c'è il problema di conversione in mysql.... puoi cercare di visualizzarli in qualche modo? salvarli su file o mostrarli tramite php? -- Domenico L. icq: 645 44 861 per stupire mezz'ora basta un libro di storia, io cercai di imparare la Treccani a memoria... [F.d.A.] From michel a ziobudda.net Thu Nov 23 16:08:41 2006 From: michel a ziobudda.net (Davide Michel 'ZioBudda' Morelli) Date: Thu Nov 23 16:17:53 2006 Subject: [Db] Programma per progettazione DB Message-ID: <4565B979.305@ziobudda.net> Ciao all. Ho un DB da risistemare. Ho la struttura delle tabelle, ma vorrei riuscire a ricreare le intersezioni tra di esse. Mi potete consigliare un software dove poter "disegnare" queste intersezioni ? Magari che funzioni sotto Linux. Grazie PS: mi sa' che mi sono spiegato da cani. Scusate. -- Michel 'ZioBudda' Morelli michel@ziobudda.net Consulenza sistemistica in ambito OpenSource. Sviluppo applicazioni web dinamiche (LAMP+Ajax) Telefono: +39-0240706096 -- Fax: +39-0291390660 http://www.ziobudda.net ICQ: 58351764 http://www.ziobuddalabs.it Skype: zio_budda http://www.ajaxblog.it From giovanni.cappellini a gmail.com Thu Nov 23 16:25:20 2006 From: giovanni.cappellini a gmail.com (Giovanni Cappellini) Date: Thu Nov 23 16:32:31 2006 Subject: [Db] Programma per progettazione DB In-Reply-To: <4565B979.305@ziobudda.net> References: <4565B979.305@ziobudda.net> Message-ID: <4565BD60.9040900@gmail.com> Davide Michel 'ZioBudda' Morelli wrote: > Ciao all. Ho un DB da risistemare. Ho la struttura delle tabelle, ma > vorrei riuscire a ricreare le intersezioni tra di esse. Mi potete > consigliare un software dove poter "disegnare" queste intersezioni ? > Magari che funzioni sotto Linux. > > Grazie > > PS: mi sa' che mi sono spiegato da cani. Scusate. DBDesigner 4 Open source visual database designer for MySQL for Windows and Linux KDE/Gnome. fabforce.net/dbdesigner4/ From cristiano a verondini.it Thu Nov 23 16:27:32 2006 From: cristiano a verondini.it (Cristiano Verondini) Date: Thu Nov 23 16:35:07 2006 Subject: [Db] Programma per progettazione DB References: <4565B979.305@ziobudda.net> <4565BD60.9040900@gmail.com> Message-ID: <02f101c70f14$1121aa50$6301a8c0@IdeaFutura.local> >> fabforce.net/dbdesigner4/ Questo è stato comprato da MySQL, quindi trovi le nuove versioni nelle suite di applicativi MySQL. Cris -- Cristiano Verondini http://www.verondini.it --- [ICQ: 114 190] From michel a ziobudda.net Thu Nov 23 16:37:33 2006 From: michel a ziobudda.net (Davide Michel 'ZioBudda' Morelli) Date: Thu Nov 23 16:44:29 2006 Subject: [Db] Programma per progettazione DB In-Reply-To: <02f101c70f14$1121aa50$6301a8c0@IdeaFutura.local> References: <4565B979.305@ziobudda.net> <4565BD60.9040900@gmail.com> <02f101c70f14$1121aa50$6301a8c0@IdeaFutura.local> Message-ID: <4565C03D.20005@ziobudda.net> Cristiano Verondini ha scritto: >>> fabforce.net/dbdesigner4/ > > Questo è stato comprato da MySQL, quindi trovi le nuove versioni > nelle suite di applicativi MySQL. > A me non va ::(((( (mysql-workbench-bin:7399): Gtk-WARNING **: Unable to locate theme engine in module_path: "qtengine", The program 'mysql-workbench-bin' received an X Window System error. This probably reflects a bug in the program. The error was 'BadMatch (invalid parameter attributes)'. (Details: serial 638 error_code 8 request_code 143 minor_code 5) (Note to programmers: normally, X errors are reported asynchronously; that is, you will receive the error a while after causing it. To debug your program, run it with the --sync command line option to change this behavior. You can then get a meaningful backtrace from your debugger if you break on the gdk_x_error() function.) Uffi... M. -- Michel 'ZioBudda' Morelli michel@ziobudda.net Consulenza sistemistica in ambito OpenSource. Sviluppo applicazioni web dinamiche (LAMP+Ajax) Telefono: +39-0240706096 -- Fax: +39-0291390660 http://www.ziobudda.net ICQ: 58351764 http://www.ziobuddalabs.it Skype: zio_budda http://www.ajaxblog.it From giovanni.cappellini a gmail.com Thu Nov 23 16:43:22 2006 From: giovanni.cappellini a gmail.com (Giovanni Cappellini) Date: Thu Nov 23 16:50:30 2006 Subject: [Db] Programma per progettazione DB In-Reply-To: <02f101c70f14$1121aa50$6301a8c0@IdeaFutura.local> References: <4565B979.305@ziobudda.net> <4565BD60.9040900@gmail.com> <02f101c70f14$1121aa50$6301a8c0@IdeaFutura.local> Message-ID: <4565C19A.6060007@gmail.com> Cristiano Verondini wrote: >>> fabforce.net/dbdesigner4/ > > Questo è stato comprato da MySQL, quindi trovi le nuove versioni > nelle suite di applicativi MySQL. A voglia io di aspettare gli aggiornamenti! -_- From ml a tassoman.com Thu Nov 23 18:06:31 2006 From: ml a tassoman.com (Tassoman (mailing)) Date: Thu Nov 23 18:13:44 2006 Subject: [Db] Programma per progettazione DB In-Reply-To: <4565C03D.20005@ziobudda.net> References: <4565B979.305@ziobudda.net> <4565BD60.9040900@gmail.com> <02f101c70f14$1121aa50$6301a8c0@IdeaFutura.local> <4565C03D.20005@ziobudda.net> Message-ID: <1164301591.11882.21.camel@localhost> Il giorno gio, 23/11/2006 alle 16.37 +0100, Davide Michel 'ZioBudda' Morelli ha scritto: > Cristiano Verondini ha scritto: > >>> fabforce.net/dbdesigner4/ > > > > Questo è stato comprato da MySQL, quindi trovi le nuove versioni > > nelle suite di applicativi MySQL. > > > > A me non va ::(((( > > Uffi... Sembrerebbe che non va a nessuno. Ne parlavo con Fullo su icq l'altro giorno... carta penna e manazza open source. ;) -- Blogging humanum est, Tassoman ovest. http://blog.tassoman.com From leodav a tiscali.it Thu Nov 23 18:29:23 2006 From: leodav a tiscali.it (Leonardo) Date: Thu Nov 23 18:34:37 2006 Subject: [Db] Programma per progettazione DB In-Reply-To: <1164301591.11882.21.camel@localhost> References: <4565B979.305@ziobudda.net> <4565C03D.20005@ziobudda.net> <1164301591.11882.21.camel@localhost> Message-ID: <200611231829.23734.leodav@tiscali.it> Alle 18:06, giovedì 23 novembre 2006, Tassoman (mailing) ha scritto: > Il giorno gio, 23/11/2006 alle 16.37 +0100, Davide Michel 'ZioBudda' > > Morelli ha scritto: > > Cristiano Verondini ha scritto: > > >>> fabforce.net/dbdesigner4/ > > > > > > Questo è stato comprato da MySQL, quindi trovi le nuove versioni > > > nelle suite di applicativi MySQL. > > > > A me non va ::(((( > > > > Uffi... > > Sembrerebbe che non va a nessuno. Ne parlavo con Fullo su icq l'altro > giorno... carta penna e manazza open source. > > ;) A me dava un errore sull' ambiente GRT ed ho risolto modificando l'ultima riga dello script che lo avvia (/usr/bin/mysql-workbench) in questo modo: LANG=C $PRG-bin $args. Ora si avvia ma è mooolto instabile. Preferisco usare la versione di DBDesigner4 per windows facendola girare su Wine. Leonardo From gianiaz a gianiaz.net Thu Nov 23 18:56:41 2006 From: gianiaz a gianiaz.net (Giovanni Battista Lenoci) Date: Thu Nov 23 19:03:55 2006 Subject: [Db] Programma per progettazione DB In-Reply-To: <200611231829.23734.leodav@tiscali.it> References: <4565B979.305@ziobudda.net> <4565C03D.20005@ziobudda.net> <1164301591.11882.21.camel@localhost> <200611231829.23734.leodav@tiscali.it> Message-ID: <4565E0D9.7020902@gianiaz.net> Leonardo ha scritto: > >>> A me non va ::(((( >>> >>> A me su win funge, devo solo capire come usarlo :P ciao :) -- gianiaz.net di Giovanni Battista Lenoci P.le Bertacchi 66 23100 Sondrio cell. +39.392.7096936 From ml a tassoman.com Thu Nov 23 19:21:06 2006 From: ml a tassoman.com (Tassoman (mailing)) Date: Thu Nov 23 19:28:18 2006 Subject: [Db] [MYSQL] da 4.0.x a 4.1.y (o meglio 5.0.z ? ) Message-ID: <1164306066.11882.36.camel@localhost> Ciao a tutti, vorrei aggiornare il mio server a php4.4.x ma sembra che apt dia dipendenza con il pacchetto php4-mysql il quale è legato a libmysql14 nettuno:~# apt-get -o Debug::pkgProblemResolver=yes dist-upgrade Lettura della lista dei pacchetti in corso... Fatto Generazione dell'albero delle dipendenze in corso... Fatto Calcolo dell'aggiornamento in corso... Starting Starting 2 Investigating libmysqlclient14 Package libmysqlclient14 has broken dep on mysql-common Considering mysql-common 12 as a solution to libmysqlclient14 7 Holding Back libmysqlclient14 rather than change mysql-common Investigating php4-mysql Package php4-mysql has broken dep on libmysqlclient14 Considering libmysqlclient14 7 as a solution to php4-mysql 21 Removing php4-mysql rather than change libmysqlclient14 Investigating libdbd-mysql-perl Package libdbd-mysql-perl has broken dep on libmysqlclient14 Considering libmysqlclient14 7 as a solution to libdbd-mysql-perl 8 Holding Back libdbd-mysql-perl rather than change libmysqlclient14 [...] Done Fatto Credo che il problema sia l'aver fissato a 4.0.* la versione di mysql-server che apt deve ottenere dai repository. Se mettessi mysql 4.1 gli script php sarebbero stravolti? Dovendo far la faticata di risistemare tutto, sarebbe quindi meglio passare definitivamente alla versione 5 sia di mysql che di php? La vedo un po' drastica. Sono in un limbo di versioni. -- Blogging humanum est, Tassoman ovest. http://blog.tassoman.com From simone a tomato.it Fri Nov 24 11:12:19 2006 From: simone a tomato.it (Simone Fumagalli) Date: Fri Nov 24 11:19:00 2006 Subject: [Db] Caratteri non standard in DB oracle In-Reply-To: <455C2DEA.9050307@pleiade.it> References: <455C29E0.1010802@tomato.it> <455C2DEA.9050307@pleiade.it> Message-ID: <4566C583.10401@tomato.it> Rieccomi, ho risolto. Il dump era esportato con charset AMERICAN_AMERICA.WE8ISO8859P1 Per importarlo correttamente ho dovuto 1) Ricreare il DB con questo charset 2) Cambiare il valore di local machine -> software - > oracle-> home0 ->nls_lang con : AMERICAN_AMERICA.WE8ISO8859P1 3) Effettuare l'import Anche nella impostazioni della connessione da Java ho impostato il charset AMERICAN_AMERICA.WE8ISO8859P1 Grazie per le info. Simone > Allora fai le cose per passi: > Sul client che charset è impostato? potrebbe bastarti : > export NLS_LANG=ITALIAN_ITALY.WE8MSWIN1252 > > prima di lanciare il programmino. > > Detto questo c'è il problema di conversione in mysql.... > > puoi cercare di visualizzarli in qualche modo? salvarli su file o > mostrarli tramite php? From domenico.lorusso a pleiade.it Fri Nov 24 11:27:44 2006 From: domenico.lorusso a pleiade.it (Domenico L.) Date: Fri Nov 24 11:33:22 2006 Subject: [Db] Caratteri non standard in DB oracle In-Reply-To: <4566C583.10401@tomato.it> References: <455C29E0.1010802@tomato.it> <455C2DEA.9050307@pleiade.it> <4566C583.10401@tomato.it> Message-ID: <4566C920.10301@pleiade.it> Simone Fumagalli ha scritto: > Rieccomi, ho risolto. > > Il dump era esportato con charset AMERICAN_AMERICA.WE8ISO8859P1 > > Per importarlo correttamente ho dovuto > > 1) Ricreare il DB con questo charset > 2) Cambiare il valore di > local machine -> software - > oracle-> home0 ->nls_lang > con : AMERICAN_AMERICA.WE8ISO8859P1 > 3) Effettuare l'import > > Anche nella impostazioni della connessione da Java ho impostato il > charset AMERICAN_AMERICA.WE8ISO8859P1 > ottimo, cmq il problema è la parte dopo il WE8ISO8859P1 la parte prima influenza le metodologia di ordinamento, il formato delle date e i messaggi di oracle c'è piena compadibilita tra american e italian nota i charset con cui si crea il db in oracle sono irreversibili... è una delle cose cui prestare mooooolta attenzione ciao -- Domenico L. icq: 645 44 861 per stupire mezz'ora basta un libro di storia, io cercai di imparare la Treccani a memoria... [F.d.A.] From cesare a ngi.it Sun Nov 26 11:39:44 2006 From: cesare a ngi.it (Cesare D'Amico) Date: Sun Nov 26 11:47:25 2006 Subject: [Db] Storicizzazione prezzi con statistiche Message-ID: <200611261139.45019.cesare@ngi.it> Hola todos, devo gestire un magazzino (N magazzini) e le relative vendite di prodotti, con riassortimenti durante la stagione, ecc. Quello che mi mette in dubbio è come gestire i prezzi: per ogni prodotto (identificato da codice, taglia e colore) devo sapere sia a quanto l'ho comprato che a quanto l'ho venduto, in modo da fornire una statistica a fine stagione. Però nel mezzo ci sono i riassortimenti, a prezzi di solito diversi dagli acquisti a inizio stagione - e in un certo momento potrei avere prodotti che vengono venduti allo stesso prezzo ma sono stati acquistati a prezzi diversi. Qual è la maniera migliore per gestire queste problematiche a livello di database? Possibilmente, per ogni tripla codice/taglia/colore, NON vorrei dover inserire una riga per ogni articolo fisico con il relativo prezzo, ma poter gestire una giacenza di magazzino. Confido in voi, non so decidermi su quale sia la soluzione migliore :) Ciaps, grazie ce -- Cesare D'Amico | Gruppo Volta Area tecnica | Web & Mkt Solutions Tel: 045 21 000 84 | Via Leida 8 - Verona Fax: 045 21 000 85 | http://www.gruppovolta.it -- Cesare D'Amico | Gruppo Volta Area tecnica | Web & Mkt Solutions Tel: 045 21 000 84 | Via Leida 8 - Verona Fax: 045 21 000 85 | http://www.gruppovolta.it From cesare a ngi.it Sun Nov 26 11:41:44 2006 From: cesare a ngi.it (Cesare D'Amico) Date: Sun Nov 26 11:49:25 2006 Subject: [Db] Storicizzazione prezzi con statistiche In-Reply-To: <200611261139.45019.cesare@ngi.it> References: <200611261139.45019.cesare@ngi.it> Message-ID: <200611261141.44296.cesare@ngi.it> Alle 11:39, domenica 26 novembre 2006, Cesare D'Amico ha scritto: > Confido in voi, non so decidermi su quale sia la soluzione migliore Specifico anche che io ho in db tutti gli scontrini col prezzo di vendita, quello che non riesco a decidermi su come fare è come associare a questo prezzo di vendita il corretto prezzo di acquisto... Ancora grazie! ce -- Cesare D'Amico | Gruppo Volta Area tecnica | Web & Mkt Solutions Tel: 045 21 000 84 | Via Leida 8 - Verona Fax: 045 21 000 85 | http://www.gruppovolta.it -- Cesare D'Amico | Gruppo Volta Area tecnica | Web & Mkt Solutions Tel: 045 21 000 84 | Via Leida 8 - Verona Fax: 045 21 000 85 | http://www.gruppovolta.it From cristiano a verondini.it Sun Nov 26 12:00:06 2006 From: cristiano a verondini.it (Cristiano Verondini) Date: Sun Nov 26 12:07:56 2006 Subject: [Db] Storicizzazione prezzi con statistiche In-Reply-To: <200611261139.45019.cesare@ngi.it> References: <200611261139.45019.cesare@ngi.it> Message-ID: <95AC1261-ECB1-48D2-B0CC-F1C95D7156ED@verondini.it> On 26/nov/06, at 11:39, Cesare D'Amico wrote: > Possibilmente, per ogni tripla codice/taglia/colore, NON vorrei dover > inserire una riga per ogni articolo fisico con il relativo prezzo, ma > poter gestire una giacenza di magazzino. Bhe, sul DB puoi tenere un record per ogni gruppo codice/taglia/ colore acquistato ad un certo prezzo. Il vero problema è: quando vendo un certo capo, supponenedo di avere comprato due stock a due diversi prezzi, come facco a sapere a quale dei gruppi apparteneva? Cioé, mentre nel carico del magazzino è facile individuare cosa inserisco e a che prezzo, quando scarico, come faccio a risalire all'articolo? Cris -- Cristiano Verondini http://www.verondini.it --- [ICQ 114 190] From cesare a ngi.it Sun Nov 26 12:34:49 2006 From: cesare a ngi.it (Cesare D'Amico) Date: Sun Nov 26 12:42:32 2006 Subject: [Db] Storicizzazione prezzi con statistiche In-Reply-To: <95AC1261-ECB1-48D2-B0CC-F1C95D7156ED@verondini.it> References: <200611261139.45019.cesare@ngi.it> <95AC1261-ECB1-48D2-B0CC-F1C95D7156ED@verondini.it> Message-ID: <200611261234.50078.cesare@ngi.it> Alle 12:00, domenica 26 novembre 2006, Cristiano Verondini ha scritto: >         Bhe, sul  DB puoi tenere un record per ogni gruppo > codice/taglia/ colore acquistato ad un certo prezzo. Il vero problema > è: quando vendo un certo capo, supponenedo di avere comprato due > stock a due diversi prezzi, come facco a sapere a quale dei gruppi > apparteneva? Cioé, mentre nel carico del magazzino è facile > individuare cosa inserisco e a che prezzo, quando scarico, come > faccio a risalire all'articolo? Ecco, questo è proprio il problema che vorrei (e DEVO) risolvere :) Potrei conteggiare tutti i carichi con il relativo prezzo di acquisto e vedere quanti scarichi ho fatto, considerando anche quelli rubati, appartati e fallati, per vedere "a che punto" sono arrivato nelle vendite, ma la cosa mi pare un po' aleatoria... -- Cesare D'Amico | Gruppo Volta Area tecnica | Web & Mkt Solutions Tel: 045 21 000 84 | Via Leida 8 - Verona Fax: 045 21 000 85 | http://www.gruppovolta.it From cristiano a verondini.it Sun Nov 26 14:46:16 2006 From: cristiano a verondini.it (Cristiano Verondini) Date: Sun Nov 26 14:54:04 2006 Subject: [Db] Storicizzazione prezzi con statistiche In-Reply-To: <200611261234.50078.cesare@ngi.it> References: <200611261139.45019.cesare@ngi.it> <95AC1261-ECB1-48D2-B0CC-F1C95D7156ED@verondini.it> <200611261234.50078.cesare@ngi.it> Message-ID: <7B84906D-220F-4E75-9027-B0BDC2C538A0@verondini.it> On 26/nov/06, at 12:34, Cesare D'Amico wrote: > Ecco, questo è proprio il problema che vorrei (e DEVO) risolvere :) > > Potrei conteggiare tutti i carichi con il relativo prezzo di > acquisto e > vedere quanti scarichi ho fatto, considerando anche quelli rubati, > appartati e fallati, per vedere "a che punto" sono arrivato nelle > vendite, ma la cosa mi pare un po' aleatoria... Questa però non è una questione tecnica, ma amministrativa. Devono dirti i committenti come comportarti a fronte della vendita di un pezzo ... :) -- Cristiano Verondini http://www.verondini.it --- [ICQ 114 190] From cesare a ngi.it Sun Nov 26 14:58:36 2006 From: cesare a ngi.it (Cesare D'Amico) Date: Sun Nov 26 15:06:21 2006 Subject: [Db] Storicizzazione prezzi con statistiche In-Reply-To: <7B84906D-220F-4E75-9027-B0BDC2C538A0@verondini.it> References: <200611261139.45019.cesare@ngi.it> <200611261234.50078.cesare@ngi.it> <7B84906D-220F-4E75-9027-B0BDC2C538A0@verondini.it> Message-ID: <200611261458.37394.cesare@ngi.it> Alle 14:46, domenica 26 novembre 2006, Cristiano Verondini ha scritto: >         Questa però non è una questione tecnica, ma amministrativa. > Devono   dirti i committenti come comportarti a fronte della vendita > di un pezzo ... :) In che senso? Io da specifiche devo storicizzare i prezzi e fornire prezzo di acquisto e di vendita di ogni pezzo venduto (sono negozi di abbigliamento, quindi TANTI pezzi)... vorrei trovare dal punto di vista tecnico una soluzione ottimale :) -- Cesare D'Amico | Gruppo Volta Area tecnica | Web & Mkt Solutions Tel: 045 21 000 84 | Via Leida 8 - Verona Fax: 045 21 000 85 | http://www.gruppovolta.it From cristiano a verondini.it Sun Nov 26 18:24:24 2006 From: cristiano a verondini.it (Cristiano Verondini) Date: Sun Nov 26 18:32:13 2006 Subject: [Db] Storicizzazione prezzi con statistiche In-Reply-To: <200611261458.37394.cesare@ngi.it> References: <200611261139.45019.cesare@ngi.it> <200611261234.50078.cesare@ngi.it> <7B84906D-220F-4E75-9027-B0BDC2C538A0@verondini.it> <200611261458.37394.cesare@ngi.it> Message-ID: <128B0574-8BFD-414A-9073-051FEBA18ADF@verondini.it> On 26/nov/06, at 14:58, Cesare D'Amico wrote: > In che senso? Io da specifiche devo storicizzare i prezzi e fornire > prezzo di acquisto e di vendita di ogni pezzo venduto (sono negozi di > abbigliamento, quindi TANTI pezzi)... vorrei trovare dal punto di > vista > tecnico una soluzione ottimale :) Allora userei una soluzione a due tabelle, la prima contiene i dati dei prodotti, la seconda, in join con la prima, contiene i dati di fornitura. Così per un serto prodotto di un certo colore ed una certa taglia, ho un rifornimento arrivato il giorno tale, di tot pezzi, pagato x, ma anche un altro arrivato in un giorno diverso pagato un prezzo diverso. Quello che sollevavo era il problema per la gestione dello scarico del magazzino in relazione ai prezzi, ma se non ti interessa direi che così sei a posto! :) Cris -- Cristiano Verondini http://www.verondini.it --- [ICQ 114 190] From cesare a ngi.it Sun Nov 26 18:30:39 2006 From: cesare a ngi.it (Cesare D'Amico) Date: Sun Nov 26 18:38:25 2006 Subject: [Db] Storicizzazione prezzi con statistiche In-Reply-To: <128B0574-8BFD-414A-9073-051FEBA18ADF@verondini.it> References: <200611261139.45019.cesare@ngi.it> <200611261458.37394.cesare@ngi.it> <128B0574-8BFD-414A-9073-051FEBA18ADF@verondini.it> Message-ID: <200611261830.40277.cesare@ngi.it> Alle 18:24, domenica 26 novembre 2006, Cristiano Verondini ha scritto: >         Quello che sollevavo era il problema per la gestione dello > scarico   del magazzino in relazione ai prezzi, ma se non ti > interessa direi che così sei a posto! :) Er, temo di non cogliere il problema.... ma forse è l'ora e la release (che procede da ieri) di 2 grossi siti interconnessi :D Puoi spiegarmi, quando hai un attimo, cosa intendi per "problema per la gestione dello scarico magazzino in relazione ai prezzi" ? Grazie per l'idea della doppia tabella, domani quando ho un cm³ di cervello libero ci dò un'occhiata ;) Ciaps, ce -- Cesare D'Amico | Gruppo Volta Area tecnica | Web & Mkt Solutions Tel: 045 21 000 84 | Via Leida 8 - Verona Fax: 045 21 000 85 | http://www.gruppovolta.it From michel a ziobudda.net Sun Nov 26 18:55:35 2006 From: michel a ziobudda.net (michel) Date: Sun Nov 26 19:04:24 2006 Subject: [Db] Storicizzazione prezzi con statistiche In-Reply-To: <200611261830.40277.cesare@ngi.it> References: <200611261139.45019.cesare@ngi.it> <200611261458.37394.cesare@ngi.it> <128B0574-8BFD-414A-9073-051FEBA18ADF@verondini.it> <200611261830.40277.cesare@ngi.it> Message-ID: <4569D517.8040306@ziobudda.net> Cesare D'Amico ha scritto: > Puoi spiegarmi, quando hai un attimo, cosa intendi per "problema per la > gestione dello scarico magazzino in relazione ai prezzi" ? > Cesare, senza minimamente volerti offendere e non sapendo le tue conoscenze di questo argomento (magazino), ti consiglio di leggere un libro sull'argomento di gestione dei magazini. Alle superiori ho fatto ragioneria ed i magazini sono sempre un po' ostici. Ti potrestri trovare a dover gestire una situazione del tipo: hai fatto 3 rifornimenti (per comodità sempre di 300 pezzi) della merce X, pagati (e chiamati per brevità) Y1, Y2, Y3. Al momento temporate T1 (diciamo dopo l'arrivo del secondo rifornimento) hai venduto 400pezzi di X. Come li scarichi ? Tutto Y1 e 100 di Y2, metà e metà ? Scarichi Y2 perche' hai il maggiore guadagno ? Al tempo T2, magari un giorno dopo T1, ti arriva un secondo ordine, ma questa volta devi fare del sottocosto. Quali vendi ? Pensi che sia arrivato il momento di fare un ordine di acquisto o speri di non finire le scorte con la vendita numero 3 ? La gestione di un magazino non è cosa semplice, e se ti mancano le basi rischi di fornire al tuo cliente un prodotto che ti si potrebbe poi ripercuotere contro (mancato guadagno da parte del cliente che si trova a dover fornire 100pezzi del prodotto X, ma il tuo programma non aveva calcolato (ad esempio) il sottoscorta. M. From cristiano a verondini.it Sun Nov 26 19:20:09 2006 From: cristiano a verondini.it (Cristiano Verondini) Date: Sun Nov 26 19:27:59 2006 Subject: [Db] Storicizzazione prezzi con statistiche In-Reply-To: <200611261830.40277.cesare@ngi.it> References: <200611261139.45019.cesare@ngi.it> <200611261458.37394.cesare@ngi.it> <128B0574-8BFD-414A-9073-051FEBA18ADF@verondini.it> <200611261830.40277.cesare@ngi.it> Message-ID: On 26/nov/06, at 18:30, Cesare D'Amico wrote: > Puoi spiegarmi, quando hai un attimo, cosa intendi per "problema > per la > gestione dello scarico magazzino in relazione ai prezzi" ? Bhe, sempice. Supponi che tu abbia due articoli uguali, ma che hai preso a prezzi diversi. Quando ne vendi uno dei due, quale dei due stai vendendo? :) -- Cristiano Verondini http://www.verondini.it --- [ICQ 114 190] From domenico.lorusso a pleiade.it Mon Nov 27 09:03:16 2006 From: domenico.lorusso a pleiade.it (Domenico L.) Date: Mon Nov 27 09:09:26 2006 Subject: [Db] Storicizzazione prezzi con statistiche In-Reply-To: <4569D517.8040306@ziobudda.net> References: <200611261139.45019.cesare@ngi.it> <200611261458.37394.cesare@ngi.it> <128B0574-8BFD-414A-9073-051FEBA18ADF@verondini.it> <200611261830.40277.cesare@ngi.it> <4569D517.8040306@ziobudda.net> Message-ID: <456A9BC4.2080906@pleiade.it> michel ha scritto: > Cesare D'Amico ha scritto: >> Puoi spiegarmi, quando hai un attimo, cosa intendi per "problema per >> la gestione dello scarico magazzino in relazione ai prezzi" ? >> > > La gestione di un magazino non è cosa semplice, e se ti mancano le > basi rischi di fornire al tuo cliente un prodotto che ti si potrebbe > poi ripercuotere contro (mancato guadagno da parte del cliente che si > trova a dover fornire 100pezzi del prodotto X, ma il tuo programma non > aveva calcolato (ad esempio) il sottoscorta. > Per non parlare delle politiche FIFO o LIFO che non puoi decidere tu ma devi farti dire dal committente... Cmq la proposta di Cris delle 2 tabelle è abbastanza standard e funzionale che dovrebbe permetterti di adattare i calcoli a qualsiasi esigenza. Ciao -- Domenico L. icq: 645 44 861 per stupire mezz'ora basta un libro di storia, io cercai di imparare la Treccani a memoria... [F.d.A.] From michel a ziobudda.net Mon Nov 27 10:20:19 2006 From: michel a ziobudda.net (Davide Michel 'ZioBudda' Morelli) Date: Mon Nov 27 10:28:12 2006 Subject: [Db] Meglio enum o un id ? Message-ID: <456AADD3.107@ziobudda.net> Ciao all. Mi trovo in questa situazione: all'interno di una tabella ho un campo che puo' avere al massimo 5 valori. Pensavo di utilizzare un valore numerico (tinyint), ma poi mi sono domandato il perche' non utilizzare l'enum('valore1','valore2',....) [uso MySQL]. Secondo la vostra esperienza è piu' veloce (nelle query di select) l'id o l'enum ? Nel senso è piu' veloce: SELECT * from tabella where id_pippo = 1 oppure SELECT * from tabella where id_pippo = 'valore1' ? Grazie. M. -- Michel 'ZioBudda' Morelli michel@ziobudda.net Consulenza sistemistica in ambito OpenSource. Sviluppo applicazioni web dinamiche (LAMP+Ajax) Telefono: +39-0240706096 -- Fax: +39-0291390660 http://www.ziobudda.net ICQ: 58351764 http://www.ziobuddalabs.it Skype: zio_budda http://www.ajaxblog.it From domenico.lorusso a pleiade.it Mon Nov 27 11:04:48 2006 From: domenico.lorusso a pleiade.it (Domenico L.) Date: Mon Nov 27 11:11:05 2006 Subject: [Db] Meglio enum o un id ? In-Reply-To: <456AADD3.107@ziobudda.net> References: <456AADD3.107@ziobudda.net> Message-ID: <456AB840.4040008@pleiade.it> Davide Michel 'ZioBudda' Morelli ha scritto: > Ciao all. Mi trovo in questa situazione: all'interno di una tabella ho > un campo che puo' avere al massimo 5 valori. Pensavo di utilizzare un > valore numerico (tinyint), ma poi mi sono domandato il perche' non > utilizzare l'enum('valore1','valore2',....) [uso MySQL]. > > Secondo la vostra esperienza è piu' veloce (nelle query di select) > l'id o l'enum ? > Nel senso è piu' veloce: > > SELECT * from tabella where id_pippo = 1 > > oppure > > SELECT * from tabella where id_pippo = 'valore1' ? > > Grazie. > mah un confronto stringa è più lento... ma non sono queste dimensioni che di solito si prendono in considerazione per valutare i tempi di un db. Detto questo un campo enum è molto più chiaro e gestibile, inoltre se ho ben capito di evita un join (operazione molto pesante) Ciao -- Domenico L. icq: 645 44 861 per stupire mezz'ora basta un libro di storia, io cercai di imparare la Treccani a memoria... [F.d.A.] From michel a ziobudda.net Mon Nov 27 11:07:08 2006 From: michel a ziobudda.net (Davide Michel 'ZioBudda' Morelli) Date: Mon Nov 27 11:15:04 2006 Subject: [Db] Meglio enum o un id ? In-Reply-To: <456AB840.4040008@pleiade.it> References: <456AADD3.107@ziobudda.net> <456AB840.4040008@pleiade.it> Message-ID: <456AB8CC.9030904@ziobudda.net> Domenico L. ha scritto: > > Detto questo un campo enum è molto più chiaro e gestibile, inoltre se > ho ben capito di evita un join (operazione molto pesante) Perche' mi evita una join ? Non ho una tabella che mi associ id_pippo a valore_pippo. valore_pippo è una cosa interna al programma PHP. Ah, grazie per la risposta. M. -- Michel 'ZioBudda' Morelli michel@ziobudda.net Consulenza sistemistica in ambito OpenSource. Sviluppo applicazioni web dinamiche (LAMP+Ajax) Telefono: +39-0240706096 -- Fax: +39-0291390660 http://www.ziobudda.net ICQ: 58351764 http://www.ziobuddalabs.it Skype: zio_budda http://www.ajaxblog.it From domenico.lorusso a pleiade.it Mon Nov 27 11:12:03 2006 From: domenico.lorusso a pleiade.it (Domenico L.) Date: Mon Nov 27 11:18:10 2006 Subject: [Db] Meglio enum o un id ? In-Reply-To: <456AB8CC.9030904@ziobudda.net> References: <456AADD3.107@ziobudda.net> <456AB840.4040008@pleiade.it> <456AB8CC.9030904@ziobudda.net> Message-ID: <456AB9F3.5000200@pleiade.it> Davide Michel 'ZioBudda' Morelli ha scritto: > Domenico L. ha scritto: >> >> Detto questo un campo enum è molto più chiaro e gestibile, inoltre se >> ho ben capito di evita un join (operazione molto pesante) > > Perche' mi evita una join ? > Non ho una tabella che mi associ id_pippo a valore_pippo. > valore_pippo è una cosa interna al programma PHP. beh in questo caso è solo una questione di gusti, io preferisco l'enum, per tornare alla tua domanda originaria un campo numerico è più veloce nei confronti, ma non credo riuscirai a misurare queste diversità... :-) ciao -- Domenico L. icq: 645 44 861 per stupire mezz'ora basta un libro di storia, io cercai di imparare la Treccani a memoria... [F.d.A.] From ml a tassoman.com Mon Nov 27 11:28:26 2006 From: ml a tassoman.com (Tassoman (mailing)) Date: Mon Nov 27 11:36:44 2006 Subject: [Db] Meglio enum o un id ? In-Reply-To: <456AB9F3.5000200@pleiade.it> References: <456AADD3.107@ziobudda.net> <456AB840.4040008@pleiade.it> <456AB8CC.9030904@ziobudda.net> <456AB9F3.5000200@pleiade.it> Message-ID: <1164623306.7081.23.camel@localhost> Il giorno lun, 27/11/2006 alle 11.12 +0100, Domenico L. ha scritto: > beh in questo caso è solo una questione di gusti, io preferisco l'enum, > per tornare alla tua domanda originaria un campo numerico è più veloce > nei confronti, ma non credo riuscirai a misurare queste diversità... :-) Enum torna comodo quando non si usano interi. M|F nord|sud|est|ovest -- Blogging humanum est, Tassoman ovest. http://blog.tassoman.com From michel a ziobudda.net Mon Nov 27 11:28:57 2006 From: michel a ziobudda.net (Davide Michel 'ZioBudda' Morelli) Date: Mon Nov 27 11:36:51 2006 Subject: [Db] Meglio enum o un id ? In-Reply-To: <456AB9F3.5000200@pleiade.it> References: <456AADD3.107@ziobudda.net> <456AB840.4040008@pleiade.it> <456AB8CC.9030904@ziobudda.net> <456AB9F3.5000200@pleiade.it> Message-ID: <456ABDE9.1090903@ziobudda.net> Domenico L. ha scritto: > beh in questo caso è solo una questione di gusti, io preferisco > l'enum, per tornare alla tua domanda originaria un campo numerico è > più veloce nei confronti, ma non credo riuscirai a misurare queste > diversità... :-) > Se non ci riesco allora vado di enum. Anche se poi nei linguaggi non compilati come il PHP o il Perl il controllo sul numero è piu' veloce di quello sulle stringhe. E su siti molto grossi anche pochi cicli di clock sono importanti. Mi sa' che scegliero' il numero per risparmiare tempo, anche se l'enum mi piaceva. Ciao. -- Michel 'ZioBudda' Morelli michel@ziobudda.net Consulenza sistemistica in ambito OpenSource. Sviluppo applicazioni web dinamiche (LAMP+Ajax) Telefono: +39-0240706096 -- Fax: +39-0291390660 http://www.ziobudda.net ICQ: 58351764 http://www.ziobuddalabs.it Skype: zio_budda http://www.ajaxblog.it From michel a ziobudda.net Mon Nov 27 11:30:32 2006 From: michel a ziobudda.net (Davide Michel 'ZioBudda' Morelli) Date: Mon Nov 27 11:38:31 2006 Subject: [Db] Meglio enum o un id ? In-Reply-To: <1164623306.7081.23.camel@localhost> References: <456AADD3.107@ziobudda.net> <456AB840.4040008@pleiade.it> <456AB8CC.9030904@ziobudda.net> <456AB9F3.5000200@pleiade.it> <1164623306.7081.23.camel@localhost> Message-ID: <456ABE48.2060105@ziobudda.net> Tassoman (mailing) ha scritto: > > Enum torna comodo quando non si usano interi. M|F nord|sud|est|ovest > Cosa centra scusa ? Posso sempre trasformare gli enum in numeri. M. -- Michel 'ZioBudda' Morelli michel@ziobudda.net Consulenza sistemistica in ambito OpenSource. Sviluppo applicazioni web dinamiche (LAMP+Ajax) Telefono: +39-0240706096 -- Fax: +39-0291390660 http://www.ziobudda.net ICQ: 58351764 http://www.ziobuddalabs.it Skype: zio_budda http://www.ajaxblog.it From cesare a ngi.it Mon Nov 27 11:51:03 2006 From: cesare a ngi.it (Cesare D'Amico) Date: Mon Nov 27 11:58:55 2006 Subject: [Db] Storicizzazione prezzi con statistiche In-Reply-To: References: <200611261139.45019.cesare@ngi.it> <200611261830.40277.cesare@ngi.it> Message-ID: <200611271151.03370.cesare@ngi.it> Alle 19:20, domenica 26 novembre 2006, Cristiano Verondini ha scritto: > On 26/nov/06, at 18:30, Cesare D'Amico wrote: > > Puoi spiegarmi, quando hai un attimo,  cosa intendi per "problema   > > per la > > gestione dello scarico magazzino in relazione ai prezzi" ? > >         Bhe, sempice. Supponi che tu abbia due articoli uguali, ma > che hai   preso a prezzi diversi. Quando ne vendi uno dei due, quale > dei due stai vendendo? :) Argh, anche in relazione a quanto detto da Michel. Qualche link? Qualche keyword? -- Cesare D'Amico | Gruppo Volta Area tecnica | Web & Mkt Solutions Tel: 045 21 000 84 | Via Leida 8 - Verona Fax: 045 21 000 85 | http://www.gruppovolta.it From cesare a ngi.it Mon Nov 27 11:54:51 2006 From: cesare a ngi.it (Cesare D'Amico) Date: Mon Nov 27 12:02:41 2006 Subject: [Db] Storicizzazione prezzi con statistiche In-Reply-To: <200611271151.03370.cesare@ngi.it> References: <200611261139.45019.cesare@ngi.it> <200611271151.03370.cesare@ngi.it> Message-ID: <200611271154.51605.cesare@ngi.it> Alle 11:51, lunedì 27 novembre 2006, Cesare D'Amico ha scritto: > Argh, anche in relazione a quanto detto da Michel. Qualche link? > Qualche keyword? Qualche titolo di libro? -- Cesare D'Amico | Gruppo Volta Area tecnica | Web & Mkt Solutions Tel: 045 21 000 84 | Via Leida 8 - Verona Fax: 045 21 000 85 | http://www.gruppovolta.it From cesare a ngi.it Mon Nov 27 12:07:08 2006 From: cesare a ngi.it (Cesare D'Amico) Date: Mon Nov 27 12:15:00 2006 Subject: [Db] Storicizzazione prezzi con statistiche In-Reply-To: <456A9BC4.2080906@pleiade.it> References: <200611261139.45019.cesare@ngi.it> <4569D517.8040306@ziobudda.net> <456A9BC4.2080906@pleiade.it> Message-ID: <200611271207.08649.cesare@ngi.it> Alle 09:03, lunedì 27 novembre 2006, Domenico L. ha scritto: > > La gestione di un magazino non è cosa semplice, e se ti mancano le > > basi rischi di fornire al tuo cliente un prodotto che ti si > > potrebbe poi ripercuotere contro (mancato guadagno da parte del > > cliente che si trova a dover fornire 100pezzi del prodotto X, ma il > > tuo programma non aveva calcolato (ad esempio) il sottoscorta. > > Per non parlare delle politiche FIFO o LIFO che non puoi decidere tu > ma devi farti dire dal committente... Mmm, direi che prendo un libro entro oggi. Io semplicemente avevo pensato di applicare l'ultimo prezzo a cui erano arrivati i prodotti, prendendolo in automatico dal listino che mi viene passato (si tratta di negozi monofornitore, quindi questo dato mi viene passato dal fornitore stesso come prezzo consigliato su cui possono essere applicate delle promozioni). Mercoledì ho un incontro con il committente e vedrò di sviscerare questo tipo di problemi, intanto grazie mille a tutti per avermi aperto gli occhi... vedrò di documentarmi entro brevissimo ;) Ciaps, grazie ancora ce -- Cesare D'Amico | Gruppo Volta Area tecnica | Web & Mkt Solutions Tel: 045 21 000 84 | Via Leida 8 - Verona Fax: 045 21 000 85 | http://www.gruppovolta.it From marcello a vezz.it Mon Nov 27 15:01:37 2006 From: marcello a vezz.it (Marcello Vezzelli) Date: Mon Nov 27 15:09:31 2006 Subject: [Db] prima nota et similia Message-ID: <456AEFC1.1080000@vezz.it> Ciao a tutti, visto che la ml comincia a lievitare e ci sono thread interessanti di progettazione, vi pongo il mio quesito: sto lavorando a un progetto che coinvolge la gestione di una prima nota e 8 casse che fanno movimenti tra loro. La prima nota è relativa alla cassa principale. Ci sono 25 entrate fisse giornaliere (delle quali cambia solo l'importo) ognuna delle quali va riportata (dopo alcuni calcoli) in una tabella di riepiloghi giornalieri. La quadratura della cassa è giornaliera (ogni giorno viene verificato tutto). Alcuni inserimenti in prima nota sono retroattivi (vanno alcuni giorni indietro) quindi si ripercuotono sulla situazione attuale della cassa. Come database ho scelto mysql. Inizialmente avevo previsto una struttura più generica possibile, ma la situazione diventava complessa rapidamente e correvo il rischio di introdurre errori nel computo di cassa. Sto meditando di fare una struttura forse non ottimale, ma che mi permette un controllo maggiore su tutto il conteggio... ovvero 1 record con 25 campi per le entrate fisse giornaliere (PK di tipo data), poi una tabella per cassa con i movimenti incrociati relativi a quel giorno (PK surrogata, il solito autoincrementante). Per evitare di sommare molti record e fare troppi conti, sto pensando di inserire una "chiusura" nel giornaliero, con i saldi delle casse, visto che gli inserimenti retroattivi vanno al massimo 15 giorni indietro. In questo modo, faccio i conti dall'ultima chiusura fino al giorno attuale (dovrò farli lato applicazione senza usare SUM). In questo modo, ad ogni aggiornamento, devo scorrere un numero di record basso... Poi devo aggiornare tutti i record con le loro chiusure giornaliere quando si fa un inserimento retroattivo per avere una situazione sempre coerente. Vi sembra una impostazione coerente? Ci sono modi migliori per una cosa del genere? No, non ho fatto ragioneria :) Saluti Marcello From cesare a ngi.it Mon Nov 27 15:03:50 2006 From: cesare a ngi.it (Cesare D'Amico) Date: Mon Nov 27 15:11:45 2006 Subject: [Db] Storicizzazione prezzi con statistiche In-Reply-To: <4569D517.8040306@ziobudda.net> References: <200611261139.45019.cesare@ngi.it> <200611261830.40277.cesare@ngi.it> <4569D517.8040306@ziobudda.net> Message-ID: <200611271503.50619.cesare@ngi.it> Alle 18:55, domenica 26 novembre 2006, michel ha scritto: > Quali vendi ? Pensi che sia arrivato il momento di fare un ordine di > acquisto o speri di non finire le scorte con la vendita numero 3 ? Premessa: le segg sono domande, non presuppongo niente :) Da un punto di vista concettuale è indifferente vendere uno o l'altro? O no? Nel senso, ho 10 lettori DVD comprati a 20? e altri 10 identici comprati a 25?. Se ne vendo 5 a 50? e poi 5 a 40?; è indifferente che "venda" (imposti come venduto) il prodotto da 20 o da 25?? Il risultato, alla fine, è che ho acquistato per 450? e venduto per 450?, tenendomi in casa 10 lettori... o mi sfugge qualcosa? Però mi sa che andiamo OT..... :( Ciaps ce PS: come si sarà capito non sono esperto di gestione magazzino, finora per fortuna non mi era mai successo di dovermi sbattere con una cosa così... studierò al più presto... :| -- Cesare D'Amico | Gruppo Volta Area tecnica | Web & Mkt Solutions Tel: 045 21 000 84 | Via Leida 8 - Verona Fax: 045 21 000 85 | http://www.gruppovolta.it From marcello a vezz.it Mon Nov 27 15:07:02 2006 From: marcello a vezz.it (Marcello Vezzelli) Date: Mon Nov 27 15:14:58 2006 Subject: [Db] Meglio enum o un id ? In-Reply-To: <456AADD3.107@ziobudda.net> References: <456AADD3.107@ziobudda.net> Message-ID: <456AF106.5030203@vezz.it> Davide Michel 'ZioBudda' Morelli ha scritto: > Secondo la vostra esperienza è piu' veloce (nelle query di select) > l'id o l'enum ? In Pascal (ma credo sia una cosa generica) gli interi sono sempre + veloci degli enum, in particolare le valutazioni sui set di enum sono molto più lente di confronti con interi. Probabilmente in MySql la differenza è minima, bisognerebbe fare qualche benchmark (o trovare qualcuno che li ha già fatti) Saluti Marcello From AlberT a superalbert.it Mon Nov 27 15:12:10 2006 From: AlberT a superalbert.it (Emiliano Gabrielli (aka AlberT)) Date: Mon Nov 27 15:20:20 2006 Subject: [Db] Meglio enum o un id ? In-Reply-To: <456AF106.5030203@vezz.it> References: <456AADD3.107@ziobudda.net> <456AF106.5030203@vezz.it> Message-ID: <200611271512.10794.AlberT@superalbert.it> On Monday 27 November 2006 15:07, Marcello Vezzelli wrote: > In Pascal (ma credo sia una cosa generica) gli interi sono sempre + > veloci degli enum, in particolare le valutazioni sui set di enum sono > molto più lente di confronti con interi. in certi casi l'enforcement che i vincoli sul DB possono dare alla integrità dei dati, già a livello di DB e non di mera app, valgono bene qualche ciclo di CPU .. :-) -- From domenico.lorusso a pleiade.it Mon Nov 27 15:23:44 2006 From: domenico.lorusso a pleiade.it (Domenico L.) Date: Mon Nov 27 15:29:54 2006 Subject: [Db] Storicizzazione prezzi con statistiche In-Reply-To: <200611271503.50619.cesare@ngi.it> References: <200611261139.45019.cesare@ngi.it> <200611261830.40277.cesare@ngi.it> <4569D517.8040306@ziobudda.net> <200611271503.50619.cesare@ngi.it> Message-ID: <456AF4F0.5020508@pleiade.it> Cesare D'Amico ha scritto: > Alle 18:55, domenica 26 novembre 2006, michel ha scritto: > >> Quali vendi ? Pensi che sia arrivato il momento di fare un ordine di >> acquisto o speri di non finire le scorte con la vendita numero 3 ? >> > > Se ne vendo 5 a 50? e poi 5 a 40?; è indifferente che "venda" (imposti > come venduto) il prodotto da 20 o da 25?? Il risultato, alla fine, è > che ho acquistato per 450? e venduto per 450?, tenendomi in casa 10 > lettori... o mi sfugge qualcosa? > no è vero infatti questa non è gestione di un magazzino :-) però bisogna essere certi che non si debba gestire il carico/scarico di un magazzino... ciao -- Domenico L. icq: 645 44 861 per stupire mezz'ora basta un libro di storia, io cercai di imparare la Treccani a memoria... [F.d.A.] From cesare a ngi.it Mon Nov 27 15:32:15 2006 From: cesare a ngi.it (Cesare D'Amico) Date: Mon Nov 27 15:40:17 2006 Subject: [Db] Storicizzazione prezzi con statistiche In-Reply-To: <456AF4F0.5020508@pleiade.it> References: <200611261139.45019.cesare@ngi.it> <200611271503.50619.cesare@ngi.it> <456AF4F0.5020508@pleiade.it> Message-ID: <200611271532.16143.cesare@ngi.it> Alle 15:23, lunedì 27 novembre 2006, Domenico L. ha scritto: > no è vero infatti questa non è gestione di un magazzino :-) però > bisogna essere certi che non si debba gestire il carico/scarico di un > magazzino... Ok, pensa di stare parlando con un bambino di 5 anni... in 2 parole, quali sono le operazioni necessarie per gestire il carico/scarico di un magazzino? Contabilità, registri, che altro? Grazie :) -- Cesare D'Amico | Gruppo Volta Area tecnica | Web & Mkt Solutions Tel: 045 21 000 84 | Via Leida 8 - Verona Fax: 045 21 000 85 | http://www.gruppovolta.it From domenico.lorusso a pleiade.it Mon Nov 27 15:35:18 2006 From: domenico.lorusso a pleiade.it (Domenico L.) Date: Mon Nov 27 15:41:37 2006 Subject: [Db] prima nota et similia In-Reply-To: <456AEFC1.1080000@vezz.it> References: <456AEFC1.1080000@vezz.it> Message-ID: <456AF7A6.8020007@pleiade.it> Marcello Vezzelli ha scritto: > Ciao a tutti, > visto che la ml comincia a lievitare e ci sono thread interessanti di > progettazione, vi pongo il mio quesito: > > La prima nota è relativa alla cassa principale. ehm... prima nota, prima nota... uff eppure dovrei sapere cos'è! > > Inizialmente avevo previsto una struttura più generica possibile, ma > la situazione diventava complessa rapidamente e correvo il rischio di > introdurre errori nel computo di cassa. > > Sto meditando di fare una struttura forse non ottimale, ma che mi > permette un controllo maggiore su tutto il conteggio... ovvero 1 > record con 25 campi per le entrate fisse giornaliere (PK di tipo > data), poi una tabella per cassa con i movimenti incrociati relativi a > quel giorno (PK surrogata, il solito autoincrementante). Bruttissimo I 25 movimenti fissi li puoi numerare facilmente giorno per giorno, ma soprattutto non capisco perché fare una tabella per cassa, ti complichi tremendamente la vita senza alcun vantaggio. Non p meglio una tabella unica con un campo che definisce la cassa? Per la tabellona con i 25 movimenti, sono sicuro che sia in effetti molto comoda per i riepiloghi, quindi, secondo me, è avere una tabella movimenti che, con opportuna procedura compila i dati della tabella riepilogo > > Per evitare di sommare molti record e fare troppi conti, sto pensando > di inserire una "chiusura" nel giornaliero, con i saldi delle casse, > visto che gli inserimenti retroattivi vanno al massimo 15 giorni > indietro. > In questo modo, faccio i conti dall'ultima chiusura fino al giorno > attuale (dovrò farli lato applicazione senza usare SUM). > In questo modo, ad ogni aggiornamento, devo scorrere un numero di > record basso... Perché mai non puoi usare sum? credo che basti flaggare opportunamente i record di tipo chiusura e i record di oggi. a questo punto ti serve una cosa come: dataInserimento, dataRiferimento > Poi devo aggiornare tutti i record con le loro chiusure giornaliere > quando si fa un inserimento retroattivo per avere una situazione > sempre coerente. In questo caso non ti servono le due date... forse un flag boolenao completato Mah.. il mio consiglio è di pensare db indipendent, cioè non pensare se è più o meno lungo sommare tanti record, pensa ad una struttura affidabile e flessibile. Potrebbe anche darsi che ti chiedano delle funzioni di archiviazione che risolvono il problema, però il punto è non trovarti ad avere pere e mele e volerle sommare Ciao -- Domenico L. icq: 645 44 861 per stupire mezz'ora basta un libro di storia, io cercai di imparare la Treccani a memoria... [F.d.A.] From michel a ziobudda.net Mon Nov 27 15:36:03 2006 From: michel a ziobudda.net (Davide Michel 'ZioBudda' Morelli) Date: Mon Nov 27 15:44:00 2006 Subject: [Db] Storicizzazione prezzi con statistiche In-Reply-To: <200611271503.50619.cesare@ngi.it> References: <200611261139.45019.cesare@ngi.it> <200611261830.40277.cesare@ngi.it> <4569D517.8040306@ziobudda.net> <200611271503.50619.cesare@ngi.it> Message-ID: <456AF7D3.6050806@ziobudda.net> Cesare D'Amico ha scritto: > Alle 18:55, domenica 26 novembre 2006, michel ha scritto: > >> Quali vendi ? Pensi che sia arrivato il momento di fare un ordine di >> acquisto o speri di non finire le scorte con la vendita numero 3 ? >> > > Premessa: le segg sono domande, non presuppongo niente :) > > Da un punto di vista concettuale è indifferente vendere uno o l'altro? O > no? > > Nel senso, ho 10 lettori DVD comprati a 20? e altri 10 identici comprati > a 25?. > > Se ne vendo 5 a 50? e poi 5 a 40?; è indifferente che "venda" (imposti > come venduto) il prodotto da 20 o da 25?? Non è vero. Ai fini fiscali e per la massimizzazione del profitto è diverso. Tu hai venduto per 450?, ma 1) (5*20 + 5* 25) = 225 - 450 = 225 di profitto 2) (10*20) = 200 - 450 = 250 di profitto 3) (10*25) = 250 - 450 = 200 di profitto Ricordiamoci che togliere 10 prodotti è semplice, da dove toglierli è difficile. > Il risultato, alla fine, è > che ho acquistato per 450? e venduto per 450?, tenendomi in casa 10 > lettori... o mi sfugge qualcosa? > Ti sfugge il profitto :) > Però mi sa che andiamo OT..... :( > Se non dispiace io continuerei la discussione. Sembra interessante. O forse mi sbaglio ? M. -- Michel 'ZioBudda' Morelli michel@ziobudda.net Consulenza sistemistica in ambito OpenSource. Sviluppo applicazioni web dinamiche (LAMP+Ajax) Telefono: +39-0240706096 -- Fax: +39-0291390660 http://www.ziobudda.net ICQ: 58351764 http://www.ziobuddalabs.it Skype: zio_budda http://www.ajaxblog.it -------------- parte successiva -------------- Un allegato HTML è stato rimosso... URL: http://lists.ziobudda.net/pipermail/db/attachments/20061127/abb886b4/attachment.htm From cesare a ngi.it Mon Nov 27 15:43:58 2006 From: cesare a ngi.it (Cesare D'Amico) Date: Mon Nov 27 15:51:51 2006 Subject: [Db] Storicizzazione prezzi con statistiche In-Reply-To: <456AF7D3.6050806@ziobudda.net> References: <200611261139.45019.cesare@ngi.it> <200611271503.50619.cesare@ngi.it> <456AF7D3.6050806@ziobudda.net> Message-ID: <200611271543.58860.cesare@ngi.it> Alle 15:36, lunedì 27 novembre 2006, Davide Michel 'ZioBudda' Morelli ha scritto: > > Se ne vendo 5 a 50? e poi 5 a 40?; è indifferente che "venda" > > (imposti come venduto) il prodotto da 20 o da 25?? > > Non è vero. Ai fini fiscali e per la massimizzazione del profitto è > diverso. Tu hai venduto per 450?, ma > 1) (5*20 + 5* 25) = 225 - 450 = 225 di profitto > 2) (10*20) = 200 - 450 = 250 di profitto > 3) (10*25) = 250 - 450 = 200 di profitto > > Ricordiamoci che togliere 10 prodotti è semplice, da dove toglierli è > difficile. Ma dal profitto non devo comunque togliere le giacenze di magazzino? Alla fine il totale non resta uguale? Sorry, ma di queste cose non ci capisco una mazza... > >  Il risultato, alla fine, è > > che ho acquistato per 450? e venduto per 450?, tenendomi in casa 10 > > lettori... o mi sfugge qualcosa? > >   > > Ti sfugge il profitto :) LOL :) Cmq il mio sistemino non si occupa di gestire la CONTABILITÀ della società (sennò avrei dato forfait), hanno un software apposito per quello, io mi occupo di caricare gli ordini effettuati, le liste dei prodotti arrivati, i listini prezzi, di spostare prodotti da un punto vendita a un altro (e quindi di sapere la giacenza nei vari magazzini), e di emettere gli scontrini. Per quest'ultima parte non mi serve sapere il prezzo di acquisto, se non erro (e ho già progettato un modo per collegare il sistema a dei registratori fiscali, quindi la parte di emissione per me si traduce solo nell'emettere una lista di codici e prezzi da stampare e non ho bisogno di fare niente di fiscale all'interno del programma). > > Però mi sa che andiamo OT..... :( > >   > > Se non dispiace io continuerei la discussione. Sembra interessante. O > forse mi sbaglio ? Beh, io la trovo ovviamente interessantissima :-P Ciaps e grazie ancora ce -- Cesare D'Amico | Gruppo Volta Area tecnica | Web & Mkt Solutions Tel: 045 21 000 84 | Via Leida 8 - Verona Fax: 045 21 000 85 | http://www.gruppovolta.it From domenico.lorusso a pleiade.it Mon Nov 27 15:52:41 2006 From: domenico.lorusso a pleiade.it (Domenico L.) Date: Mon Nov 27 15:59:14 2006 Subject: [Db] Storicizzazione prezzi con statistiche In-Reply-To: <456AF7D3.6050806@ziobudda.net> References: <200611261139.45019.cesare@ngi.it> <200611261830.40277.cesare@ngi.it> <4569D517.8040306@ziobudda.net> <200611271503.50619.cesare@ngi.it> <456AF7D3.6050806@ziobudda.net> Message-ID: <456AFBB9.8020601@pleiade.it> Davide Michel 'ZioBudda' Morelli ha scritto: > > Non è vero. Ai fini fiscali e per la massimizzazione del profitto è > diverso. Tu hai venduto per 450?, ma > 1) (5*20 + 5* 25) = 225 - 450 = 225 di profitto > 2) (10*20) = 200 - 450 = 250 di profitto > 3) (10*25) = 250 - 450 = 200 di profitto > > Ricordiamoci che togliere 10 prodotti è semplice, da dove toglierli è > difficile. Scusa ma in questi casi (se non diversamente espresso) non si segue sempre la politica fifo? > Se non dispiace io continuerei la discussione. Sembra interessante. O > forse mi sbaglio ? Direi proprio di no, sono cose utili! -- Domenico L. icq: 645 44 861 per stupire mezz'ora basta un libro di storia, io cercai di imparare la Treccani a memoria... [F.d.A.] From michel a ziobudda.net Mon Nov 27 15:54:18 2006 From: michel a ziobudda.net (Davide Michel 'ZioBudda' Morelli) Date: Mon Nov 27 16:02:14 2006 Subject: [Db] Storicizzazione prezzi con statistiche In-Reply-To: <200611271543.58860.cesare@ngi.it> References: <200611261139.45019.cesare@ngi.it> <200611271503.50619.cesare@ngi.it> <456AF7D3.6050806@ziobudda.net> <200611271543.58860.cesare@ngi.it> Message-ID: <456AFC1A.40205@ziobudda.net> Cesare D'Amico ha scritto: > Cmq il mio sistemino non si occupa di gestire la CONTABILITÀ della > società (sennò avrei dato forfait), hanno un software apposito per > quello, io mi occupo di caricare gli ordini effettuati, le liste dei > prodotti arrivati, i listini prezzi, di spostare prodotti da un punto > vendita a un altro (e quindi di sapere la giacenza nei vari magazzini), > e di emettere gli scontrini. Io per tagliare la testa al toro, al momento di "togliere il venduto" farei scegliere all'utente da quale "ordine di acquisto" eliminare i pezzi. Oppure con il cliente metti in chiaro che il tuo software elimina con una coda FIFO i prodotti (il primo che arriva è il primo ad uscire, senza guardare costi etc etc). Altrimenti devi scegliere con il cliente come agire. Solo lui puo' decidere. M. -- Michel 'ZioBudda' Morelli michel@ziobudda.net Consulenza sistemistica in ambito OpenSource. Sviluppo applicazioni web dinamiche (LAMP+Ajax) Telefono: +39-0240706096 -- Fax: +39-0291390660 http://www.ziobudda.net ICQ: 58351764 http://www.ziobuddalabs.it Skype: zio_budda http://www.ajaxblog.it From cristiano a verondini.it Mon Nov 27 16:01:50 2006 From: cristiano a verondini.it (Cristiano Verondini) Date: Mon Nov 27 16:09:51 2006 Subject: [Db] Meglio enum o un id ? In-Reply-To: <456AADD3.107@ziobudda.net> References: <456AADD3.107@ziobudda.net> Message-ID: <02A9D2B7-18E0-480E-B124-2D06FF846B7B@verondini.it> On 27/nov/06, at 10:20, Davide Michel 'ZioBudda' Morelli wrote: > Secondo la vostra esperienza è piu' veloce (nelle query di select) > l'id o l'enum ? AFAIK gli enum sono memorizzati nel DB come interi (a due byte direi), quindi non dovrebbe esserci sostanziale differenza (ammesso che il tempo di parse della query non venga considerato. Cris -- Cristiano Verondini http://www.verondini.it --- [ICQ 114 190] From cristiano a verondini.it Mon Nov 27 16:02:50 2006 From: cristiano a verondini.it (Cristiano Verondini) Date: Mon Nov 27 16:10:47 2006 Subject: [Db] Meglio enum o un id ? In-Reply-To: <200611271512.10794.AlberT@superalbert.it> References: <456AADD3.107@ziobudda.net> <456AF106.5030203@vezz.it> <200611271512.10794.AlberT@superalbert.it> Message-ID: <83FE09D9-D0DC-4E58-A267-0CAADA116161@verondini.it> On 27/nov/06, at 15:12, Emiliano Gabrielli (aka AlberT) wrote: > in certi casi l'enforcement che i vincoli sul DB possono dare alla > integrità > dei dati, già a livello di DB e non di mera app, valgono bene > qualche ciclo > di CPU .. :-) Sono assolutamente d'accordo. In questo senso, l'inserimento di un valore non valido in una colonna ENUM può causare, a seconda delle impostazioni del DB, l'inserimento di un valore nullo oppure il reject della query. Cris -- Cristiano Verondini http://www.verondini.it --- [ICQ 114 190] From cristiano a verondini.it Mon Nov 27 16:05:10 2006 From: cristiano a verondini.it (Cristiano Verondini) Date: Mon Nov 27 16:13:10 2006 Subject: [Db] prima nota et similia In-Reply-To: <456AEFC1.1080000@vezz.it> References: <456AEFC1.1080000@vezz.it> Message-ID: <3AED8146-E2CC-4BE0-B345-11CCB5F096A6@verondini.it> On 27/nov/06, at 15:01, Marcello Vezzelli wrote: > Inizialmente avevo previsto una struttura più generica possibile, > ma la situazione diventava complessa rapidamente e correvo il > rischio di introdurre errori nel computo di cassa. > > Sto meditando di fare una struttura forse non ottimale, ma che mi > permette un controllo maggiore su tutto il conteggio... ovvero 1 > record con 25 campi per le entrate fisse giornaliere (PK di tipo > data), poi una tabella per cassa con i movimenti incrociati > relativi a quel giorno (PK surrogata, il solito autoincrementante). > > Per evitare di sommare molti record e fare troppi conti, sto > pensando di inserire una "chiusura" nel giornaliero, con i saldi > delle casse, visto che gli inserimenti retroattivi vanno al massimo > 15 giorni indietro. > In questo modo, faccio i conti dall'ultima chiusura fino al giorno > attuale (dovrò farli lato applicazione senza usare SUM). > In questo modo, ad ogni aggiornamento, devo scorrere un numero di > record basso... > Poi devo aggiornare tutti i record con le loro chiusure giornaliere > quando si fa un inserimento retroattivo per avere una situazione > sempre coerente. > > Vi sembra una impostazione coerente? Ci sono modi migliori per una > cosa del genere? Si, ne esistono di migliori. Ti consiglio la lettura di un qualche testo sulla normalizzazione della struttura dei DB dal quale potrai trarre interessanti spunti :) Cris -- Cristiano Verondini http://www.verondini.it --- [ICQ 114 190] From lookdown a gmail.com Mon Nov 27 16:06:09 2006 From: lookdown a gmail.com (Marco Guardabasso) Date: Mon Nov 27 16:14:06 2006 Subject: [Db] Storicizzazione prezzi con statistiche In-Reply-To: <456AFC1A.40205@ziobudda.net> References: <200611261139.45019.cesare@ngi.it> <200611271503.50619.cesare@ngi.it> <456AF7D3.6050806@ziobudda.net> <200611271543.58860.cesare@ngi.it> <456AFC1A.40205@ziobudda.net> Message-ID: <30a934720611270706t37c26525x4c07146bfa71db75@mail.gmail.com> Domanda forse stupida da ignorante: i pezzi non sono identificabili in qualche altro modo che non sia la data di acquisto (codice seriale, codice a barre...)? Marco 2006/11/27, Davide Michel 'ZioBudda' Morelli : > > Cesare D'Amico ha scritto: > > Cmq il mio sistemino non si occupa di gestire la CONTABILITÀ della > > società (sennò avrei dato forfait), hanno un software apposito per > > quello, io mi occupo di caricare gli ordini effettuati, le liste dei > > prodotti arrivati, i listini prezzi, di spostare prodotti da un punto > > vendita a un altro (e quindi di sapere la giacenza nei vari magazzini), > > e di emettere gli scontrini. > > Io per tagliare la testa al toro, al momento di "togliere il venduto" > farei scegliere all'utente da quale "ordine di acquisto" eliminare i > pezzi. > Oppure con il cliente metti in chiaro che il tuo software elimina con > una coda FIFO i prodotti (il primo che arriva è il primo ad uscire, > senza guardare costi etc etc). > Altrimenti devi scegliere con il cliente come agire. Solo lui puo' > decidere. > > M. > > -- > Michel 'ZioBudda' Morelli michel@ziobudda.net > Consulenza sistemistica in ambito OpenSource. > Sviluppo applicazioni web dinamiche (LAMP+Ajax) > Telefono: +39-0240706096 -- Fax: +39-0291390660 > > http://www.ziobudda.net ICQ: 58351764 > http://www.ziobuddalabs.it Skype: zio_budda > http://www.ajaxblog.it > > > > _______________________________________________ > Db mailing list > Db@lists.ziobudda.net > http://lists.ziobudda.net/mailman/listinfo/db > > > -------------- parte successiva -------------- Un allegato HTML è stato rimosso... URL: http://lists.ziobudda.net/pipermail/db/attachments/20061127/51a7fdff/attachment.html From cristiano a verondini.it Mon Nov 27 16:06:56 2006 From: cristiano a verondini.it (Cristiano Verondini) Date: Mon Nov 27 16:14:57 2006 Subject: [Db] Storicizzazione prezzi con statistiche In-Reply-To: <200611271503.50619.cesare@ngi.it> References: <200611261139.45019.cesare@ngi.it> <200611261830.40277.cesare@ngi.it> <4569D517.8040306@ziobudda.net> <200611271503.50619.cesare@ngi.it> Message-ID: <849246E4-63D2-4A2C-9D4B-26EE52BB62D6@verondini.it> On 27/nov/06, at 15:03, Cesare D'Amico wrote: > Se ne vendo 5 a 50? e poi 5 a 40?; è indifferente che "venda" (imposti > come venduto) il prodotto da 20 o da 25?? Il risultato, alla fine, è > che ho acquistato per 450? e venduto per 450?, tenendomi in casa 10 > lettori... o mi sfugge qualcosa? Ti sfugge che potresti non venderli tutti! :)) Cris -- Cristiano Verondini http://www.verondini.it --- [ICQ 114 190] From