2014-02-16 12:33 GMT+00:00 Diego Barrera <diegonebarr...@yahoo.it>: > On 16/02/2014 12:40, enrico franchi wrote: > >> >> L'architettura del db deve essere *sempre* il piu' efficiente possibile. >> Se no, non ja fa. E si, sharda, cazzi e mazzi, per carita'. >> >> Alla luce di questo e avendo in mente che devo andare in produzione il > prima possibile, > (leggi per ora mi interessa poco scalare, ma mi server avere una killer > app per vedere come va) > che succede se opero in questo modo: > > 1. creo model e tutta app con l'orm; > 2. l'app funziona e ho tanti clienti: primi problemi a scalare > 3. ottimizzo sql e impostazioni specifiche dbms > > Mi sembra un buon compromesso. > > Se le cose funzionano veramente cosi', certo. Solo che nella pratica non succede cosi'. Succede che fra il punto 2 e il punto 3 ci sono anche le nuove features, i bug fix, vari cazzi architetturali non previsti, tutta quella parte di operations che non sapevi che esistesse e che ti devi inventare, cominciare a mettere su team di risposta alle emergenze...
Quindi tipicamente quello che fai al posto del 3 e' infilare un po' di patch, fare un po' di porcate con memcache etc etc etc. Dalla strada arrivano notizie di tutti i tipi. C'e' twitter che riscrive tutto in Scala da Ruby. Ci sono quelli che invece falliscono perche' un competitor, sebbene arrivato secondo sul mercato, ci arriva con un prodotto che funziona *anche* sotto scala e gli utenti migrano in massa. Ci sono quelli che vanno avanti a zoppicare per anni e nessuno dice nulla. -- . ..: -enrico-
_______________________________________________ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
