2010-02-21 13 views

Respuesta

19

Recomiendo usar el mismo back-end de base de datos en producción que en desarrollo, y todas las etapas intermedias. Django resumirá las cosas de la base de datos, pero tener diferentes entornos lo dejará abierto a una internacionalización horrible, problemas de configuración y pequeñas incoherencias desagradables que ni siquiera se mostrarán hasta que lo publique.

Personalmente, me quedo con MySQL, pero nunca llegué con postgres :)

+0

bien estoy contento de no haber caminado por ese camino todavía. tal vez eche un vistazo a postgres ya que puedo instalarlo en cygwin. conseguir que mysql funcione allí ha demostrado más problemas de los que merece la pena. –

+1

¿Por qué molestarse con cygwin, tanto mysql como postgres tienen paquetes win32 nativos? :) –

+0

Sé que esto es un poco tarde, pero usar XAMPP con Django ha sido un sueño, se mezcla bien para mí. Tuve algunos problemas con MySQLdb pero busqué en Google y encontré bibliotecas compiladas. Saludos, todos! :-) –

7

¿Por qué querrías hacer eso?

  • SQLite aún no tiene soporte para procedimientos almacenados.
  • SQLite es typeless. Puede terminar con muchos problemas tipocast al ejecutar MySQL.
  • También SQLite aún no es compatible con RIGHT join.
+1

Ninguno de estos afecta a ninguna de mis necesidades de Django; aunque tienes razón – analytik

3

En resumen, no; a menos que desee duplicar innecesariamente el tiempo de desarrollo.

7

I segundas todas las respuestas anteriores, añadiendo algunas razones explícitas:

  • cuestiones MySQL Advertencia excepción cuando intenta para almacenar cadenas más largas que el ancho del campo - no las obtendrá en SQLite, entonces no solo su cadena será diferente entre dev y producción, sino también el comportamiento del programa
  • errores en ambos backends son diferentes - Recuerdo que una vez Intenté SQLite para dev y MySQL para producción, pero resultó que descubrí un error en el back-end de MySQL que no estaba presente en SQLite. Así que presenté una entrada para él y cambió a MySQL para la prueba :-)

e incluso se puede tratar de competir con SQLite en términos de velocidad, echar un vistazo a mi respuesta a otra pregunta: ¿

Increase speed for MySQL table creation in Django?

+0

+1 - Excelentes contribuciones. –

5

Utilice la misma base de datos en todos los entornos.

Tanto como el ORM intenta abstraer las diferencias entre las bases de datos, siempre habrá ciertas características que se comportarán de manera diferente en función de la base de datos. La portabilidad de la base de datos es un mito completo.

Además, parece bastante loco probar y desarrollar contra las rutas de código que nunca utilizará en producción, ¿no es así?

+0

"La portabilidad de la base de datos es un mito completo" ¡GRACIAS! –

2

Acabo de cometer este gran error comenzando con sqlite y cuando trato de implementar en el servidor de producción con mysql, las cosas no funcionaron tan bien como esperaba. Intenté dumpdata/loaddata con varios modificadores, pero de alguna forma seguí recibiendo errores uno tras otro. Hágase un gran favor y use el mismo DB para producción y desarrollo.

Cuestiones relacionadas