2010/1/22 Enrico 'Henryx' Bianchi <henry...@yahoo.it>: > Di conseguenza, lo sviluppo di una base di dati, > indipendentemente dagli strumenti "intermediari" (e.g. sqlalchemy) va > implementata direttamente sul motore di database che si sta prendendo in > considerazione
Su questo sono d'accordo anche io. O meglio, sono d'accordo finché si parla di sqlite vs postgresql. Anche noi abbiamo tentato a volte di fare test su sqlite e usare postgresql in deployment ma già il fatto che non abbia chiavi per forzare l'integrità referenziale fa sorgere dei problemi. A volte comunque mi capita di far girare i test su postgresql e fare il deployment su SQL Server. Anche lì l'applicazione va testata funzionalmente su SQL Server prima di metterla in staging ovviamente, ma il compromesso funziona, soprattutto mentre stai scrivendo codice. Fortunatamente un giorno ci libereremo (o quasi) di SQL Server 2005 migrando tutto il possibile a PostgreSQL. Tutto ciò è possibile soprattutto grazie alla presenza di uno stato intermedio, perché se hai una applicazione legacy sviluppata per un DBMS in SQL e stored procedure direttamente la transizione può rivelarsi un bagno di sangue, te l'assicuro :-) -- Lawrence Oluyede [eng] http://oluyede.org - http://twitter.com/lawrenceoluyede [ita] http://www.neropercaso.it [flickr] http://www.flickr.com/photos/rhymes _______________________________________________ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
