Las migraciones pueden manejar tanto la estructura (esquema) como los datos, pero una vez que esté en funcionamiento, la suposición es que en la mayoría de los casos sus datos de producción son la fuente canónica de información. Si hay datos necesarios para configurar la base de datos, por ejemplo cosas como listas ("Mastercard, Visa, Amex) o datos de arranque (por ejemplo, configurar un usuario administrador) esto puede ir en el archivo" seeds .rb ". No hay nada integrado que hace una copia de una base de datos (esquema y contenido) y se aplica automáticamente -. este sería típicamente una cosa de una sola vez
(Going the otra dirección - la copia de la base de datos de producción a las instancias de control de calidad o de desarrollo es un caso de uso común. Al principio, podría pensar: Rails debería poder hacer esto. Pero copiar una base de datos de producción típica puede estar llena de problemas. El más importante es: copiar una base de datos de producción con información de usuario es un riesgo de seguridad significativo ; cualquier operación de copia debería, como mínimo, anonimizar a los usuarios. Un segundo problema es solo el tamaño de la base de datos: una base de datos de producción a menudo es útil o incluso necesario para reproducir problemas de rendimiento de la vida real u otros casos extremos, pero cualquier base de datos grande tardará mucho tiempo en replicarse y depende en gran medida de la base de datos específica que esté utilizando y de los permisos)
En resumen, Rails hace lo correcto con la migración: asume que las actualizaciones estructurales son correctas, pero requiere que complete los datos. ¡Espero que esto ayude!
¿quiere decir que tiene datos en su caja local que desea en producción? ¿Cuántos datos es? ¿Completando tablas de búsqueda? – natedavisolds