How to update the database schema and data in production?

Please explain how usually update the data in production, where the means and even changing the very structure of the database.
Example: let's say there is a table with users, where only 2 fields id and fio. Accordingly, in the drive name field, the data in the "Name Surname Patronymic". And then there was a need to change the table structure by breaking the field fio on 3 fields surname, firstname, middlename. But in production there are already 1000+ entries in this table.
If you make changes on the LAN, and run migration in production, the data is removed. As I understand it, before that data with users somewhere save and then pour. How is that done? And where to make these changes with data on LAN or on production?
June 7th 19 at 14:46
3 answers
June 7th 19 at 14:48
Because the issue of transformation of the available data, then individually for each task.

Start from here:
And, in fact, to come to the conclusion that it is better to leave it as is in a single field. If some areas need other forms of calls - to register them explicitly, and not designing on an existing misconceptions about the name.

And so:
0) is an additional backup
1) rolls alter table to add new fields
2) rolls out the application, able to write simultaneously the new and old structure, but reading only the old
3) a separate process in the cycle of small pieces is converted to the data - if it is subject to automatic processing
4) roll out the application using only the new structure
5) is backed up and deleted the original structure

For only some thousands of records may be easier to lock the plate for a few seconds.

If trivial automatics is not processed, it often, instead of 3 points make unloading primary key, source_data, somehow change and prepare csv primary key, source_data, new_data, copy to temporary table, then doing the merge multitabling update these two tables with recheck'ω source_data. Then unload the data which are not updating, we understand, again, update, etc. just to fill.
0) made a backup :) - vito.Hoeg commented on June 7th 19 at 14:51
indeed, it is worth to explicitly mention this point - Ignacio_Romaguera commented on June 7th 19 at 14:54
June 7th 19 at 14:50
and run migration in production, the data is removed.

It's kind of a bad migration if the data is removed. Well, more precisely it is not migration but it is not clear what.
Case that you is this (if it is possible to stop the application at the time of migration, if not then it will be harder of course):
1) created a new column;
2) filled in the insert-select th-th partitioning on the fly;
3) deleted the original column.
An example of just such a partitioning that you need
June 7th 19 at 14:52
Thank you!

Find more questions by tags DatabasesMigration of data