Newsgroup: it.lavoro.informatica
Titolo: Problemi appassionanti.

A tutti quelli che lavorano nell' IT o vorrebbero farlo chiedo quali
problematiche tecniche piacerebbe loro affrontare affinche` il lavoro
possa risultare appagante (o interessante).

 possa risultare appagante (o interessante).
Anni fa sviluppavo giochi da bar comprendenti anche la "versione" soft-core 
abilitabile da setup interno (sfondi, personaggi, ecc).
La mia ditta non poteva assumere troppe persone, quindi la cernita del 
materiale a disposizione era fatta da noi programmatori o dai pochi grafici.
Il lavoro era interessante... Anzi, direi il classico lavoro "duro"... :) 
Bei tempi.........
:-P
-- 
__________________________
Luc (32, CO)
MS Visual Studio developer
__________________________

 possa risultare appagante (o interessante).
Personalmente, la parte tecnica del lavoro per me è sempre appagante e
interessante. Quello che crea problemi è quando:
1) Il cliente non sa quello che vuole e/o quello che gli serve
(moooolto frequente come caso);
2) Il commerciale o il PM che ha parlato con il cliente (se il cliente
non è un mio cliente diretto) non ha capito una mazza e/o non sa
trasmettermi quello che serve al cliente (altretanto frequente per i
commerciali, per i PM un po' meno, ma succede anche).


Se c'è una cosa che ancora mi rode, è nel non aver avuto modo di capire
bene le problematiche legate al tuning e ottimizzazione dei DB (MS SQL
Server in particolare).
Voglio dire che personalmente mi piacerebbe riuscire a raggiungere quelle
competenze che ti permettano di identificare e risolvere i colli di
bottiglia nella gestione dei DB.
Ciao, Alessandro
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 bottiglia nella gestione dei DB.
Prendi il programmatore che ha scritto la query. Mandalo a fare un corso
su "Il giusto modo di scrivere query" e dopo vedrai che i colli di
bottiglia si eliminano da soli.
-- 
Hi, I'm a .signature virus! Copy me to your .signature file and
help me propagate, thanks!

 abilitabile da setup interno (sfondi, personaggi, ecc).
in che periodo?
-- 
Sayonara,
Nicolò Nyo Armato
www.nyosources.com
Desainah $w*3+c insaid


Simpatico. 
Ti informo che "saper scrivere la query" è solo un tassello del puzzle
sulla questione.



Metodi, processi e librerie per sviluppare meglio.

 sulla questione.
Allora ho sempre avuto fortuna. Il 95% dei problemi sui DB che ho
risolto, dipendevano da query scritte col culo.



Se ti va di contestualizzare un po' di più per me si può anche proseguire
con la discussione.


Direi ogni interfacciamento con HW... dal registratore di cassa alle
linee di produzione con PLC.
Al3x

 in che periodo?
'95-'98 circa. 


 linee di produzione con PLC.
Se chi programma il partner di comunicazione non è un "cazzone" direi 
che è veramente carina come cosa; se, come mi è capitato, chi progetta 
il software (e l'hardware) del partner di comunicazione fa delle scelte 
discutibili, anche il sottoscritto deve fare i salti mortali per poi 
avere qualcosa di "instabile".
Ciao!
Francesco

 possa risultare appagante (o interessante).
Anche se non comprendo lo spirito della domanda, a me piace il debug e 
l'ottimizzazione! ...se ovviamente ho in mano degli strumenti efficienti 
ed efficaci!
Ciao!!
Francesco

 con la discussione.
C'e' poco da contestualizzare, e tantomeno da discutere. Ti parlo per la
mia esperienza personale. Il 90% dei colli di bottiglia che ho anche
adesso su qualsiasi DB (Oracle,MySQL e PostgreSQL) e' sempre dovuto
a query del cavolo scritte dai programmatori. Poi guarda caso son sempre
i soliti...


 a query del cavolo scritte dai programmatori.
Un esempio, ti prego, un esempio! 


> Un esempio, ti prego, un esempio! 
L'ultima era una query con una join di 8 tabelle.



E che aveva che non andava?


 E che aveva che non andava?
Lo sviluppatore o quello che ha disegnato il DB.


 possa risultare appagante (o interessante).
La problematica che preferirei affrontare in assoluto sarebbe: "come 
potrò spendere la barca di soldi che ricevero' con la prossima notula".
-- 
Fabrizio "Hermooz" Ermini

 
Il che in se non è un male, bisogna vedere come è fatto il join...
-- 
Ciao!
Luca

 Lo sviluppatore o quello che ha disegnato il DB.
Non necessariamente, anche se in effetti, forse, in quel caso una buona 
SP è più indicata.
-- 
Ciao!
Luca

 SP è più indicata.
Ovvio stiamo ragionando per astratto senza avere nessun elemento alla mano
per cui tutto quello che diciamo non ha nessuna valenza. In generale pero'
pochi sono gli sviluppatori che conoscono bene i meccanismi di un DB o che
usano qualche tool di ottimizzazione per query. MS predilige le SP in nome
dell'efficienza, j2ee le rinnega in quanto attribuiscono logica ad un
layer che dovrebbe occuparsi solo di data. Alla fine la scelta migliore va
valutata caso per caso (ma perche' un dataview no?).



Le SP non è che fanno miracoli, il tempo di compilazione e la generazione
del piano di esecuzione occupano una frazione del tempo complessivo per la
risoluzione della SP (almeno in MS SQL Server).
Se si parla di query critiche la dove bisogna stare attenti anche ai
millisecondi allora è un conto, ma dove invece si vuole guadagnare tempo
in elaborazioni che sono dell'ordine dei secondi, usare una SP piuttosto
che comandi SQL inviati al volo fa ben poca differenza (a meno di
condizioni limite quasi non documentate in cui il server si "impalla" e
alle quali seguono fix varie).
Credo che l'uso delle SP sia da ricercare, più che per questioni di
prestazioni, per necessità di isolare la parte server dal client, rendere
il DB più sicuro e pulito, e fare in modo che l'applicativo finale sia
meglio manutentibile.
Ciao, Alessandro


 Ciao, Alessandro
Ciao
Stefano Grevi


Sono d'accordo.


 possa risultare appagante (o interessante).
Complimenti per la domanda.
Molti problemi di lavoro derivano dalla mancata risposta a questa domanda.
Ovviamente qualsiasi risposta genera discussioni infinite.

 possa risultare appagante (o interessante).
Il mio sogno e' lavorare nei videogame online. In particolare sul DB.
Purtroppo non e' facile perche ci sono 5 aziende al mondo a malapena che
lo fanno seriamente e ovviamente non sono in Italia e non lo saranno mai.
Nicola


esecuzione. In SP complesse (quelle che fanno ricerche usando viste
mah, secondo microsoft, stored o sql dinamico ma con parametri
dichiarati, hanno una esecuzione molto più rapida. Infatti SqlServer
tiene una cache delle query eseguite, se ha già eseguito una query va
a ripescare il suo piano di esecuzione. Logico che lo può fare solo
con sql dinamico con parametri dichiarati o con le stored.
Rifare il piano di esecuzione è costosissimo, e il motore di
esecuzione cerca di evitarlo in qualunque modo (sempre a sentire
l'esperto MS di SqlServer).
Un bel problema è invece che gli sviluppatori ottimizzano al
millisecondo la pagina per la gestione utenti (usata 2 volte il mese) e
scrivo la peggiore query del mondo per loggare le visite ad ogni
ricarica di pagina...

 risolto, dipendevano da query scritte col culo.
Palese. Ma si parla di performance, non di "problemi". Per le
performance devi saper usare l'ottimizzatore che non è li a caso, e non
è banalissimo ...
  ngw

 i soliti...
Prendendo solo PostgreSQL (che è poi quello che conosco) c'è ampia
letteratura sul planning e sull'esecuzione delle query, e anche la lista
di Postgres tratta spesso quegli argomenti.
Se la query è scritta con i piedi è chiaro che il problema è quello, ma
quello di cui si parlava era conoscere a fondo il DBMS utilizzato in
modo da poterlo ottimizzare in presenza di colli di bottiglia _non_
dovuti all'incapacità del DBA o del programmatore, ma ad esempio di una
query corretta che però risulta troppo lenta per la mole di dati che
deve trattare. E' li che entrano in gioco quelle competenze, non nel
mettere apposto una query incasinata.
  ngw

 possa risultare appagante (o interessante).
web, web, web, web :)
  ngw

 di Postgres tratta spesso quegli argomenti.
Mi mandi un indirizzo email valido, che ti chiedo un paio di cose?
Grazie.
-- 
Ciao!
Luca


Quello che intendevo con il post iniziale era proprio il concetto di
arrivare ad imparare a raccogliere i dati (via profiler e performance
counter) per capire cosa stia realmente succedendo, avendo in
contemporanea capacità di verificare la struttura del DB con query/sp
associate.
Da qui tirare la somma per ogni caso concreto analizzato e saper suggerire
il giusto compromesso per risolvere i problemi di performance riscontrati
(oltre al troppo ovvio, ma anche giusto, suggerimento di rifare magari la
struttura del...)
Una specie di DBA specializzato, come lo chiamano, "performance
optimization".


 Ovviamente qualsiasi risposta genera discussioni infinite.
Non vero a giudicare dallo sviluppo del thread!
Era tanto per fare un statistica e capire le ambizioni e l'eta` media di
di chi legge e scrive qui.
Io penso di averla intuita abbastanza bene ma comunque non mi esprimo (non
si sa mai).

 possa risultare appagante (o interessante).
Al di là delle singole problematiche tecniche che per 
un "tecnico" di natura hanno tutte le loro parte di fascino, mi 
piacerebbe evolvere costantemente. Sembra l'uovo di Colombo, 
eppure credo che non sia così frequente nel mondo del lavoro 
riuscire piano piano a crescere nel tempo facendo bagaglio delle 
esperienze passate. Sono più facili cambi repentini di attività 
o contesto per insoddisfazione oppure promozioni contrattuali, 
ma che raramente portano ad una reale crescita. 
Un esempio? Cominciare ad occuparsi di programmazione "nuda e 
cruda" in un determinato settore, passare all'analisi, 
proseguire allo studio dei progetti, arrivare alle consulenze 
con il cliente e terminare magari con un'azienda propria ove 
applicare il tutto. Con questa prospettiva ogni lavoro diventa 
appagante :-)
--  
Postato da Virgilio Newsgroup: scopri i nuovi gruppi 
Eros, foto e video a 
http://newsgroup.eros.virgilio.it

 ngw
Nicola
 
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

 risolto, dipendevano da query scritte col culo.
Ti assicuro che spesso continuano ad esistere problemi anche se scrivi
bene le query.
Per esempio, che ne pensi di tabelle senza indice o con indici
scazzati? anche la "query migliore" deve fare un full-table scan ad
ogni select. In questo caso è il DB che deve essere ottimizzato, non
la query.
Ma è solo un esempio.
La mia esperienza è esattamente opposta. Il software in genere non è
scritto malissimo, è il DB che deve essere ottimizzato.
Cordiali saluti
Marco.

 Lo sviluppatore o quello che ha disegnato il DB.
Quindi, il problema può benissimo essere nel DB, non nella query in
sé... :-)
Cordiali saluti
Marco.

 scritto malissimo, è il DB che deve essere ottimizzato.
Probabilmente significa che hai sempre trovato programmatori che
sapevano programmare.
