Newsgroup: it.lavoro.informatica
Titolo: Parole Proibite!

Il mio project manager(stamattina era abbastanza schizzato, tipo 
balbetta e chiude e riapre la penna 15 o 20 volte al secondo):
"D-D-D-Dati questi 2 parametri DataDiPubblicazione e DataDiAggiornamento 
  valorizzati con la stessa identica data(senza orario) per 
es.05/03/2009 come facciamo a cc-c-c-apire se un contenuto relativo alla 
data(non accessibile) e' variato lo stesso giorno?"
All'inizio ho pensato ma questo ci e' o ci fa o e' bruciato,parla a 
caso... Cmq gli ho detto:"Non mi sembra possibile!"
si sono incazzati come le bestie perche' ho detto la parola impossibile! :-D
e mi hanno accusato che dico troppe volte "non si puo fare"
Ditemi che sto sognando!A volte mi chiedo se ho a che fare con dei 
programmatori o dei commerciali ottusi!
cya



Guarda che ti basta ribattere con un "Tu come faresti?" e poi smontare
tutte le stronzate che ti tira fuori nei 5 minuti successivi...
Saluti.
-- 
Living in Barbaropoli
http://www.barbaropoli.com

 :-D
La prossima volta fai cosě:
http://www.youtube.com/watch?v=rdkecMOT1ko

 programmatori o dei commerciali ottusi!
Ammetto di aver subito un po' di lavaggio del cervello ai tempi ma
parole come:
- non si può fare
- impossibile
- errore
- problema
non vannno davvero mai dette (soprattutto davanti al cliente!).
I "problemi" o "errore" sono "anomalie" o "funzionamenti non voluti",
"impossibile" invece "nulla è impossibile, con un giga€uro e il giusto
tempo tutto è possibile...".
Lo so sono mezze seghe mentali che se programmi e basta puoi pensare
inutili ma davanti al cliente non lo sono per nulla...
Vai te a farti pagare da un cliente dopo che gli hai detto "ti ho
sistemato l'errore"... mente è diverso se gli dici "ti ho sistemato
quel funzionamento che era diverso da come ti aspettavi" (se poi
invece di "ti ho sistemato" ci infili un "ho implementato" è ancora
meglio)!
Al3x


Appunto, te digli che troppe volte ti fanno le domande sbagliate :-)
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

I "problemi" o "errore" sono "anomalie" o "funzionamenti non voluti",
FEATURES, si chiamano FEATURES.
Trenta e passa anni di Microsoft e ancora non avete imparato niente.
Tze. :)



Ancora meglio, si dice "by-design", almeno in MS il termine tira tanto in
sostituzione di bug... :-)


 non si tratta di lavaggio del cervello, ma di semplice verita'.
Concordo pienamente!
Al3x

 Trenta e passa anni di Microsoft e ancora non avete imparato niente.
C'hai ragione c'hai!!
Al3x

 sostituzione di bug... :-)
Bella... vediamo quando riesco a usarla per la prima volta!!
Al3x

 propositivo.
Giusto! + proposizione = + lavoro = + soldi!
Al3x
PS: del + beghe non ne parlo ;-)

 bisogna sempre essere propositivi, 
e se 4r4g0rn_AtWork avesse studiato gli autori classici in latino...   ;-)
-- 
DES

 e mi hanno accusato che dico troppe volte "non si puo fare" 
questo come minimo vuol dire che non è la prima volta che capita? :)
c'è un mio collega che, sistematicamente, ad ogni richiesta la sua prima 
risposta è "non si può fare" o (se va bene) "è un casino". poi si discute 
e viene fuori che non è così, perché spesso c'è spazio per rivedere 
alcuni prerequisiti o magari basta cambiare punto di vista. 
non ti nascondo che questo modo di fare il primo approccio al problema lo 
trovo molto irritante e per nulla costruttivo.
naturalmente non voglio insinuare che tu sia in questo modo, però capisco 
anche l'altra parte. la prossima volta se hai dubbi sulla fattibilità 
rispondi "parliamone".

 rispondi "parliamone".
ok ma mi sa che me ne vado via prima ne ho le balls piene! :-D

 si puo' fare e scegliamo un'altra strada... eppoi cosa cazzo si incazza!!!
potresti avere una tabella dove memorizzi i cambiamenti, o se usi un db 
crearla con un trigger...

 e mi hanno accusato che dico troppe volte "non si puo fare"
Succede anche a me, e raramente ho torto sul fatto che sia veramente 
"impossibile"... :) 
-- 
_______________________
Luc (35, CO)
Statement has no effect
_______________________

 
Prima o poi ci obbligheranno tutti a fare un corso di PNL 
(programmazione neurolinguistica).

 crearla con un trigger...
si ok , ma e' chiaro che *solamente* con la data non si puo' fare 
occorre fare un controllo sui contenuti.
Ora perche' si ostinava a ragionare su quella fottuta data?E' come se 
uno mi dicesse A=1 e B=1 come faccio a vedere se A!=B
LOL
non e' possibile (vedi mi viene naturale)perche' sono uguali, PD!!!non 
bisogna manco farsi sti problemi!
L'orario non c'e' perche' c'e' solo a pagamento , siccome il cliente non 
vuole pagare devo ravanare i dati da delle pagine web in cui non viene 
pubblicato l'orario ma solo il giorno, quindi se ci sono delle 
variazioni durante lo stesso giorno le perdono!:-D
CYA

 programmatori o dei commerciali ottusi!
La seconda che hai detto... parola di Quelo...
E magari tu non lo sai ancora, ma potrebbe anche piacerti avere a che
fare con commercialisti ottusi...
Ciao,
Marco


 tutte le stronzate che ti tira fuori nei 5 minuti successivi...
In tempi di vacche grasse avrebbe fatto quanto segue: 
poiche' il programmatore "locale" gli dice che non si puo' fare,
allora avrebbe incaricato qualcuno (un bodyrentallaro ad esempio) di
trovargli
uno che gli risolvesse il problema, dicendogli che e' disposto a spendere
molti soldi per trovare questo qualcuno.
Quando spuntava uno che gli diceva "te lo risolvo io" o quando
il bodyrentallaro gli diceva "ho trovato uno che ti risolve
il problema", questo intascava
(o meglio il bodyrentallaro intascava. Ma in tempi di vacche grasse
anche il bodyrentallato non aveva le tasche del tutto vuote) e dopo
accurata analisi comunicava al PM che il problema non aveva soluzione
(e questa volta era vero che non c'era soluzione, visto che l'aveva detto
il superesperto superpagato).
Poi le vacche sono dimagrite ... e ora si limitano ad innervosirsi.


 inutili ma davanti al cliente non lo sono per nulla...
Effettivamente non sono inutili. Sono disastrosamente dannose.
Ciao,
Marco.


Al3xI98O ha scritto:

mai sentito parlare dell'halting problem?

 mai sentito parlare dell'halting problem?
Ok, ok... quasi nulla è impossibile... ma nel campo del lavoro secondo
me il quasi sparisce...
Al3x

 propositivo.
Quoto.
Senza contare che la vedo difficile che una data sia stata memorizzata 
sul DB senza ora, a meno di essere dei VERI caproni. Comunque è vero: 
nell'informatica quasi niente è impossibile.
ciao, U.

 si sono incazzati come le bestie perche' ho detto la parola impossibile! 
Hanno ragione, tu sei li per fornire soluzioni, mica per dire "č 
impossibile". Tanto piů che il problema che descrivi non solo č 
"possibile", ma č anche probabilmente semplice da risolvere.
ciao, U.

 si sono incazzati come le bestie perche' ho detto la parola impossibile! :-D
Come ti hanno già detto altri, hai sbagliato.
Ricorda che parli con gente limitata dal punto di vista tecnico.
Tu digli che si può fare, ma non così e proponi l'alternativa.
Poi digli anche quanto tempo (= costo) ci va in più: forse non è il 
caso che hai citato tu ora, ma di solito a quel punto saranno poi loro 
a dirti che è "impossibile".

 variazioni durante lo stesso giorno le perdono!:-D
E' ovvio che per come dici tu non è possibile ottenere il risultato 
richiesto. FORSE è ottenibile analizzando la struttura dei dati e 
sfruttando dei side-effects di altri campi oppure avendo questo 
requirement è necessario prevedere altri campi/funzionalità.

CUT
Ma mi spieghi come cazzo e' che ogni volta che rispondi a qualcuno:
A) parli di soldi
B) porti esempi dove con tuoi clienti che sistematicamente non
capivano un cazzo
C) gliele hai cantate facendo vedere che a te non la si fa
Per curiosita' eh, mica per altro...
-- 
Living in Barbaropoli
http://www.barbaropoli.com

 incazza!!!
il fatto che s'incazzi fa nascere un altro ordine di problema (quello dei 
rapporti interpersonali).
faccio però notare che il solo aggiungere "scegliamo un'altra strada" 
cambia completamente il tono della risposta. "non è possibile" vuol dire 
che non esiste altra strada o comunque che trovarla siano cazzi esclusivi 
di chi te lo chiede. 
poi, ripeto, se il problema è il tono della reazione si tratta di un 
altro film che va affrontato a prescindere dal caso in questione, perché 
va a impattare nella qualità dell'ambiente lavorativo.
 

 nell'informatica quasi niente è impossibile.
Perché escludi che siano dei veri caproni? Sai quanta gente ho visto
memorizzare le date come testo invece che come date? Non ci metti l'ora,
e voilà!

 a dirti che è "impossibile".
Infatti quello che doveva dire è "è impossibile con questi dati",
affermazione inoppugnabile, seguito da "per farlo bisogna rifare 
riscrivere ricominciare da capo ecc." al quale punto erano cavoli del pm.

 programmatori o dei commerciali ottusi!
hanno ragione... "impossibile" non esiste! con i soldi e il tempo tutto si 
può fare... :D
-- 
SimBus82.net coming soon - 
http://www.simbus82.net
Photo&DGTArt - 
http://simbus82.deviantart.com/
BodyWorkout - 
http://simbus82-workout.blogspot.com/
Combatti on-line con 
http://re-caio.labrute.fr
 

 Hanno ragione, tu sei li per fornire soluzioni
Si, ma se ti dicono di fare "A", e alla fine avrebbero bisogno anche di fare 
"B", un bel "è impossibile" ci sta.


data(non accessibile) e' variato lo stesso giorno?"
Increntando di 1000 anni il valore della datadiaggiornamento, cosě
sottraendo la datadipubblicazione quando si hanno >3 migliaia e
dividendo per 1000 hai anche quante modifiche sono state fatte.
:-P
G

 si sono incazzati come le bestie perche' ho detto la parola impossibile! :-D
Tipico.
Tu tecnico sei li' per "dare soluzioni", non importa quanto
impossibile sia il farlo, ergo non lo vogliono sentire.
Come altri ti hanno detto poi magari l'impossibile e' dato da
condizioni di contorno piu' che per ragioni tecniche.
Anyway, io ho adottato spesso la "Tattica di HAL", ovvero assumo uno
sguardo da "sto facendo un lavoro della madonna nella mia mente
proprio ora" e poi fornisco come output vocale "dati insufficienti per
una risposta".
:-)
C'ya
   STeve

 :-)
si ma tirando fuori la scheda perforata sulla lingua :D

 (programmazione neurolinguistica).
Naaaaaaaaaaaaa..........come minimo qualche livello di training mentale
di Ron Hubbard.

 potrebbe anche piacerti avere a che fare con commercialisti ottusi...
se hai a che fare con commercialisti perché lavorano per te, meglio che 
non siano ottusi  ;-)
Se invece intendevi i commerciali... in fondo vale la stessa cosa: un buon 
commerciale garantisce la pagnotta a tutta la squadra, e coi tempi che 
corrono non è poco.
-- 
DES

 prevedere altri campi/funzionalità.
o leggendo il log degli update (sempre che ci sia, come dovrebbe).
[Ho imparato presto che i log servono soprattutto a pararsi il culo in 
caso di rogne, da allora traccio tutto il possibile ;-) ]
-- 
DES

 
Ha ragione, pubblicamente (>2 persone tra cui almeno uno non tecnico) 
questa parola non si dice :-)
Scusa la faccina ma è così, la risposta è:
"va approfondito", "è il caso di ragionarci su", "guardiamo come si può 
fare", ecc. dopodichè il problema si risolve da solo .


io ho risolto cosě : non dň mai la risposta subito , ma sempre dopo mezzora 
.
Anche se uno mi chiede quanto fa 1+1  , io mi prendo sempre mezzora di tempo 
, perchč come saprai
le risposte a freddo sono sempre diverse dalle risposte a caldo.
Lo sanno anche i miei interlocutori , che infatti mo pongono i quesiti via 
mail , a cui io posso risponedere dopo mezzora .
In quella mezz'ora posso addolcire la pillola , oppure argomentare meglio.

 cliente. Semplicemente non ti è concesso.
questa sarà al solito la tua esperienza di persona che, evidentemente, 
si presenta alle riunioni di lavoro con i clienti con l'autorevolezza di 
un cucciolo di dalmata.
non è mai capitato che il cliente durante una riunione imponesse a me o 
ai miei colleghi di formulare una soluzione seduta stante, francamente 
mi sfugge perché dovrebbe farlo visto che stiamo decidendo per lui.
e dire che di clienti rompicojoni ne ho avuti e ne ho tutt'ora.

    STeve
Andrea 

 L'ultima domanda (Asimov)
Il Maestro, ci si riferisce a Lui come il Maestro :-)
Bravo, vedo che hai studiato :)
C'ya
   STeve

 tempo tutto è possibile...".
si chiamano "criticita' "...zio, quanto odio sta' parola, e' l'ipocrisia di 
vestire con un bel vestito il problema piuttosto che volerlo affrontare e 
risolverlo.
dannati laureati in scienza della comunicazione.
 

 risolverlo.
Sono d'accordo, anch'io di natura sarei molto pratico, ma purtroppo non 
si può fare... forse è anche "giusto", o perlomeno è logico, se si vuole 
vendere meglio. E' chiaro che un atteggiamento simile portato allo 
stremo tende addirittura alla truffa...

 stremo tende addirittura alla truffa...
non mi sembra proprio stesse parlando di questioni commerciali. il pm 
non è un commerciale.
non credo nemmeno che dire "non è fattibile" sia la massima espressione 
del senso pratico. certo se è impossibile lo è, ma quando vedi che una 
persona ha questa risposta di default sei portato a pensare che sia 
perfettamente inutile chiedergli il parere.

 programmatori o dei commerciali ottusi!
Credo basterebbe contestualizzare la tue affermazioni, per farle 
accogliere in maniera completamente diversa.
Il ricorso a una premessa più articolata ("date le nostre risorse...", 
"dati i vincoli temporali...") od anche ad un semplice avverbio 
("attualmente") non sono cose puramente formali, ma cose che chiariscono 
e arricchiscono le informazioni che si intende comunicare.

e arricchiscono le informazioni che si intende comunicare.
Ma no, deve dire:
"Tarapio tapioca, come se fosse antani con i due campi univoci..."
E poi ribattereç
"pusterlenghi e anche speculari, nonsipuofareunasega. Con
scappellamento a destra."
Saluti.


 memorizzata sul DB senza ora.
Verissimo, infatti è importantissimo avere l'ora di nascita
nell'anagrafica,  così puoi vendere un bel pacchetto per il calcolo
dell'oroscopo completo di ascendente.
Veri caproni quelli che si ostinano a memorizzare solo la data! :-))) 

ispas ha scritto:

assolutamente no, anzi sono encomiabili. bisogna mettersi di impegno e 
inventarsi dei datatype, visto che quelli disponibili hanno (minimo) 
precisione al secondo.

 (minimo) precisione al secondo.
Certo, peccato che l'ora ce la devi valorizzare tu, non se la
valorizzano da soli. E quindi, giustamente, una pagina anagrafica che
si rispetti deve prevedere non solo l'input della data di nascita, ma
anche l'ora, il minuto e il secondo, come minimo. Ma io valuto un vero
professionista colui che ci mette anche il decimo, il centesimo ed il
millesimo, come nelle gare dei 100 metri. D'altronde, se il db lo
prevede, perchè sprecare tanto ben di Dio?? :-)))

ispas ha scritto:

quindi immagino che tu, per questa ragione, salvi le date in char(8) 
come ha detto sentenza (a cui hai risposto)?

 cya
consiglio di visionare il film "S.Y.N.A.P.S.E.",
la reazione che hai descritto è presente pari pari
in almeno una scena... ;)
ps.: Il project manager italiano è l'emblema dell'incompetenza italiana

 come ha detto sentenza (a cui hai risposto)?
Mai salvate le date come char nei db relazionali. E mai salvate certe
date (invero molto frequenti, come la nascita e tante altre)
impostandoci un'ora precisa...

ispas ha scritto:

bon.
così è chiaro l'equivoco, non avevi capito il discorso in cui ti sei 
inserito.

 sei inserito.
Io ho risposto a questo (di UC e non di Sentenza) :
"Senza contare che la vedo difficile che una data sia stata memorizzata
sul DB senza ora, a meno di essere dei VERI caproni."
Se l'italiano ha ancora qualche significato, la frase era chiarissima.
Forse formulava male il pensiero, che era riferito solo al caso
particolare del messaggio di apertura. Voglio sperare che sia così.

 sul DB senza ora, a meno di essere dei VERI caproni."
il tuo follow-up era al messaggio di sentenza che diceva:
"Perché escludi che siano dei veri caproni? Sai quanta gente ho visto
memorizzare le date come testo invece che come date? Non ci metti l'ora,
e voilà!"
quindi l'equivoco è ancora più chiaro, oltre a non aver capito ti sei 
inserito anche nel punto sbagliato. capita.

 sei inserito anche nel punto sbagliato. capita.
Ti riferisci a te? Guardati bene il follow-up, oppure sistemati il tuo
reader ;-)


ma come ti permetti!!!
ma che c@##o stai dicendo....
razza di idiota rimbecillito,
caprone ci sarai tu!!!!

 sei inserito anche nel punto sbagliato. capita.
Puoi fare di meglio. Giornata no. Capita :-)

 memorizzare le date come testo invece che come date?
cosa che peraltro _in determinate situazioni_ (tipo sistemi molto 
eterogenei, con piů db che -forzatamente- stanno alla base di un unico 
pastrocchione nato in modo X e sviluppatosi in modo WYZ) non č nemmeno 
il peggiore dei mali
d.

 il peggiore dei mali
continuo a non vederne la giustificazione.
se hai sistemi eterogenei ci saranno i sistemi di scambio dati che 
saranno scritti in modo di farli parlare fra loro con le dovute 
conversioni di tipi e dati. non č che tutti i sistemi si devono 
allineare al peggio di loro e rimanervi ancorati per tutta la vita...

 precisione al secondo.
E' vero anche questo, ma se l'oggetto è un qualcosa di cui appunto al
momento dell'immissione hai solo la data, l'ora risultante nel campo fisico
sarà sempre 00:00:00, cosa che ti serve a una sega :)

 il peggiore dei mali
Che vuol dire, in "determinate situazioni" va bene pure riparare la
moto col filo di ferro, ma non lo farei mica come regola :)

 sul DB senza ora, a meno di essere dei VERI caproni.
Perché mai?
L'SQL-92 prevede un data type che si chiama /date/, che non contiene 
l'ora (il data type con data e ora si chiama /timestamp/, ribatezzato da 
alcuni vendor come /datetime/) il cui uso, dipendentemente dal contesto, 
può essere più appropriato del timestamp.
Nel caso riferito dall'OP sembra ci sia stato un problema di 
modellazione del db: forse saranno dei caproni per quello, ma non è che 
uno lo sia automaticamente solo perché utilizza il tipo date.
Ciao.


Si era riferito all'OP, nel senso che a quanto pare si parla di
aggiornamenti di contenuti che possono variare anche nel corso di una
giornata, e modellare il campo db usando un tipo "date" (per non
parlare di char) è da caproni.
ciao, U.

 ha scritto nel messaggionews:2f21d$49b11399$d52f4787$15...@news.chello.at...

vedi ispas, questo è un fulgido esempio di utilizzo proprio del campo
datetime per le date di nascita: è fondamentale per distinguere
Anderthal dal suo eventuale fratello gemello non idiota.
ciao, U.


tuttavia la tua affermazione mi sembra abbastanza irriverente
nei confronti di alcune decine di migliaia di sviluppatori, per es.
nell'area midrange ibm, dove da decenni la data è un campo
numerico di 6 cifre, prima dell'anno 2000 e di 8 cifre poi, nel
formato capovolto aaaammgg per poter fare l'ordinamento
se era necessario avere l'ora si utilizzava un altro campo numerico
di 6 posizioni.
Ti dirò una cosa che forse non sai in passato alcuni database
neppure ce l'avevano il tipo campo data e migliaia di installazioni
di gestionali che hanno sostenuto la PMI italiana negli ultimi 30
anni ha funzionano come ho descritto sopra.
Quindi prima di dare del "caproni" a chichessia magarti rifletti un po'
 

 Quindi prima di dare del "caproni" a chichessia magarti rifletti un po'
Mi sembra ovvio che l'aggettivazione (che condivido) fosse destinata a
quegli sviluppatori che pur avendo un campo date disponibile nel database
(mi vengono in mente Oracle, PostgreSQL, Microsoft SQL Server, Firebird,
MySQL ed infine anche Access) si ostinano ad usare un campo varchar, magari
senza neanche prevedere lato frontend un minimo di controllo su quanto
inserito dall'utente.
Chi sviluppa in questo modo (e ci sono questi elementi perché ho avuto a
che fare con file di Access generati in questo modo) è per me assolutamente
ed indiscutibilmente un "caprone" e mi frega zero se qualcuno si sente
offeso da questo commento.
PaF

 ed indiscutibilmente un "caprone" 
Anche chi confonde "campo" con "tipo" non scherza mica eh...
Ciao,
Marco
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 allineare al peggio di loro e rimanervi ancorati per tutta la vita...
Sulle stringhe ho sempre potuto fare facilmente tutti i tipi di 
elaborazione possibile immaginabile,
 con estrema facilita' con qualsiasi tool 
e qualsiasi linguaggio di programmazione. 
Per altro le stringhe si prestano perfettamente a contenere date
e ore con il formato che voglio io e con la precisione che voglio io
(Quando ho iniziato a lavorare mi capitava spesso di lavorare con 
sistemi real-time dove alcune deadline erano dell'ordine del millisecondo 
e talvolta era utile avere a disposizione misurazioni del tempo
fino ai microsecondi, cosa non semplice da avere con i vari tipo "date" dei
DBMS che erano in circolazione [specialmente 10 anni fa])
Non ho mai lavorato su altri
tipi di dati sui quali si potesse fare praticamente di tutto 
(per altro mi ricordo
di essere incappato in rompimenti di zebedei perche' se non sbaglio mysql
memorizzava le date in un formato diverso da db2 [questo sempre
10 anni fa circa, oggi non saprei] per cui comunque era
necessario trasformarle in stringhe per fare delle elaborazioni e po
eventualmente ritrasformarle in date)
Se ho qualcosa di estremamente versatile e facile da usare perche'
dovrei cercare qualcosa di diverso ? Perche' le cose diverse
sono "piu' nuove?", anche se mi creano milioni di problemi che con
le stringhe non avrei ?


 moto col filo di ferro, ma non lo farei mica come regola :)
Puo' essere ma io direi che *in determinate situazioni* occorre "lavorare
di fino". E se non lo devi fare puoi anche usare delle robe grossolane,
come
i tipi date dei dbms (che sono paragonabili al fil di ferro, mentre con
le stringhe ci fai anche le microsaldature, se ti serve. Con i tipi
date ci fai quello che chi ha progettato i tipi ti consente. E non e' detto
che per te sia sufficiente).
Ciao,
Marco.


 Anche chi confonde "campo" con "tipo" non scherza mica eh...
Se proprio vogliamo filosofeggiare ti posso dire che un campo è l'istanza
di un tipo, per cui pur ammettendo l'imprecisione terminologica mi auguro
che il nucleo del mio pensiero fosse sufficientemente chiaro.
PaF

PaF ha scritto:



Piu' che filosofeggiare, volevo capire perche' avercela tanto con chi
usa dei varchar per memorizzare date, che tra tutte le possibili
porcherie che si possono fare nell' informatica mi pareva una
delle meno rilevanti (se non, a volte, addirittura necessaria).


 le stringhe non avrei ?
Ragionando in questo modo buttiamo via tutti i datatype esistenti,
utilizziamo solo i varchar e viviamo felici riscrivendo le funzioni per
sommare gli integer, float, double etc etc
PaF

 delle meno rilevanti (se non, a volte, addirittura necessaria).
Hai mai avuto tra le mani un database dove le date erano memorizzate in
stringhe e dove l'utente poteva inserire qualunque porcata senza controllo
in inserimento ?
Io si, ho perso ore per gestire tutti i casi in cui la data semplicimente
non era tale o era formattata random
- x volte con il formato dd/mm/yyyy (ok mi sta bene)
- y volte con il formato yyyy/mm/dd (ok ma perché l'utente ha cambiato ?)
- z volte yyyy (che giorni/mese mi invento ?)
- k volte del tipo 2009/02/29 o 2008/13/31 (chissà cosa pensava l'utente)
- j volte con scritto "boh" (piuttosto che lasciare vuoto scrivono boiate)
In questo caso i "caproni" sono 3:
1) chi ha creato lo schema senza i datetime
2) chi ha creato la UI gestendo le date con textbox senza alcun controllo
3) chi ha usato il programma
PaF

 sommare gli integer, float, double etc etc
Tu potrai anche non crederci, ma mi e' capitato di usare stringhe
(e bitset della STL del C++)
anche per fare addizioni e moltiplicazioni (prova a fare addizioni e
moltiplicazioni di interi a 32 o 64 byte usando integer, float e double,
poi ne riparliamo)


 le stringhe non avrei ?
Poi ci si meraviglia che le poste funzionano di merda...

 stringhe come se fossero date...
Dipende cosa ci devi fare. A me e' capitato di dover convertire,
praticamente
per forza, delle date (o meglio dei tempi) in stringhe per poi farci
le elaborazioni che mi servivano, perche' operatori e funzioni
disponibili sui tipi del DB non erano sufficienti per quello
che mi serviva (e, come dicevo a PaF, mi e' capitato anche che, ad esempio,
le operazioni che si possono fare su tipi primitivi del C++ non fossero
sufficienti a fare quello che mi serviva, ovvero addizioni e
moltiplicazioni
[ed elevazioni a potenza] su numeri interi a 32 o 64 byte: l'ho fatto
usando sostanzialmente delle stringhe).
Ciao,
Marco.


 avrei ?
/me *molto* perplesso.

Il Mon, 09 Mar 2009 14:43:12 +0100, Marcoxxx ha scritto:
[cut]
Ti faccio l'obiezione inversa: se esistono i datetime/timestamp che portano
in dote a costo zero una serie di funzioni che *prima* o *poi* dovrai usare
(non stiamo parlando del programma di gestione del ciabattino) perchè
ostinarsi ad utilizzare un varchar che quelle funzioni non le ha ?
E' come dire che in auto vuoi usare esclusivamente la quarta marcia anche
in autostrada pur avendo la quinta.
PaF

 Poi ci si meraviglia che le poste funzionano di merda...
Mi scuso per questa battutaccia: non c'era nulla di personale (tanto più 
che condivido quasi sempre quello che scrivi).
E' anche dovuto al fatto che sono veramente esacerbato con l'azienda di 
cui sopra, dove per sventura mi è toccato scontrarmi con alcune tra le 
persone più ignoranti (e arroganti) che abbia mai conosciuto in ambito 
lavorativo.
Ovviamente tu non c'entri nulla, mi scuso di nuovo.
Ciao.

 3) chi ha usato il programma
Presumo di non concordare:
l'utente non dovrebbe essere tenuto a sapere ne' quale sia il formato
scelto
dal progettista del DB, ne' quale sia il formato inserito dall'utente
che ha usato il programma prima di lui (se il programma puo' essere
usato da piu' utenti diversi). Quindi se nessuna indicazione viene data
dalla UI e nessun controllo viene fatto prima di inserire il dato
nel DB, ritengo l'utente "innocente".
Secondo me il vero "caprone" e' quello del punto 2.
Ciao,
Marco.


 [cut]


Se hai tutto quello che serve, sono d'accordo. E' che nelle poche
esperienze che ho avuto io non ho quasi mai avuto tutto quello che
mi serviva.


 Secondo me il vero "caprone" e' quello del punto 2.
In effetti ho esagerato, l'utente è un po' come un belva, se non lo metti
in gabbia può fare danni, per istinto innato :-)
PaF

 Poi ci si meraviglia che le poste funzionano di merda...
Alle poste non ho mai messo le mani sui db,
e comunque non c'e' da meravigliarsi se uno vuole fornirmi centinaia
di migliaia di funzioni che non mi servono ad un cazzo e si innervosisce
quando si usa l'unico modo possibile per implementare le uniche
due cose che mi servono (per altro in perfetto stile microsoft, direi,
almeno quando lo usavo).


 /me *molto* perplesso.
Se sei molto perplesso, prova a dover inserire in due record due
timestamp che differiscono di 1 microsecondo (e poi doverli distinguere
quando li estrai), poi dimmi se ti viene piu' l'orchite a fare una cosa
del genere o se ti viene di piu' l'orchite a fare le cose che dici tu.
Ovviamente io ad alcuni problemi (tipo le scadenze
degli ultimi 60 giorni o il venduto delle prime 15 settimane non li
consideravo perche' sono problemi con cui non ho mai avuto a che fare,
come immagino che molti non abbiano avuto a che fare con il
lavoro su intervalli di tempo molto brevi)


Il Mon, 09 Mar 2009 16:27:08 +0100, Marcoxxx ha scritto:
[cut]
Scusa Marco, tu ti sei sentito tirato in causa come se le osservazioni
fossero dirette a te personalmente.
E' chiaro che se uno ha esigenze particolari non coperte da quanto offre o
ha offerto in passato il DBMS a disposizione lo sviluppatore si organizza
come meglio crede.
E' un altro discorso sostenere che č inutile utilizzare le features a
disposizione solo perché abituati ad usare i varchar che in passato
andavano bene, questo č criticabile.
PaF

 del genere o se ti viene di piu' l'orchite a fare le cose che dici tu.
a parte che lo salverei come long integer perché con ogni probabilità è 
così che lo gestisce il linguaggio, ma mi sembra un caso un po' 
particolare. gestisci le situazioni comuni come quelle particolari?