<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">2013/12/16 enrico franchi <span dir="ltr"><<a href="mailto:enrico.franchi@gmail.com" target="_blank">enrico.franchi@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div>Dipende cosa intendi con prodotto. Siccome ho sempre un customer, nel mio caso i progetti sono in certo senso anche prodotti. </div></blockquote><div><br></div><div>se hai un solo customer, č un progetto.</div><div>
se il tuo customer č la tua azienda, che vende il prodotto che sviluppi tramite molteplici canali a migliaia di clienti finali allora direi che č un prodotto.</div>
<div>Diciamo che possiamo generalizzare dicendo che un prodotto lo sviluppi per un customer ma il cliente finale non corrisponde al tuo customer.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div>E si, se. Lo sforzo di sviluppo o di ops cresce troppo, io voto per cambiare i componenti colpevoli. Anche se sono db. <span></span> </div></blockquote></div><br><div>Scegliere il DB per un prodotto č una cosa difficile. Per esigenze di vendita in differenti realtā il requisito del tuo cliente (stessa azienda) potrebbe essere supportare i maggiori DB.</div>

<div><br></div><div>Un ORM semplifica la vita.</div>
</div></div>