|
|
|
Миграция данных со старой схемы на новую
|
|||
|---|---|---|---|
|
#18+
Добрый день. Несколько лет назад была сделана на коленке ужасная по архитектуре БД, имеющая несколько таблиц с практически одинаковыми полями (так вышло, потому что таблицы добавляли разные люди, в разное время и т.д.). Теперь есть возможность обновить как приложение, использующее эту БД, так и саму архитектуру БД. Три таблицы с практически одинаковыми полями будут слиты в одну. Однако для миграции данных существует следующая сложность. У всех таблиц было автоинкрементное поле ID целочисленное, поэтому во всех имеются одинаковые значения. При миграции в одну таблицу нужно будет заново генерировать уникальное ID поле. Однако с прежними таблицами есть множественные связи других таблиц. Вопрос: как наиболее простым способом сделать объединение данных и обновить заново сгенерированные в новой таблице ID в связанных таблицах (которые тоже, кстати, будут объединяться). Можно ли написать SQL запрос, который бы сначала скопировал все данные из первой, второй, третьей таблиц без поля ID, создавая его значение заново, а затем прошелся каким-то способом (есть foreach ?) по новой таблице и сопоставляя другое уникальное поле (есть, к счастью, такое) с полями в связанных таблицах, обновлять его значение? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.01.2019, 09:03 |
|
||
|
Миграция данных со старой схемы на новую
|
|||
|---|---|---|---|
|
#18+
java73Можно ли написать SQL запрос, который бы сначала скопировал все данные из первой, второй, третьей таблиц без поля ID, создавая его значение заново, а затем прошелся каким-то способом (есть foreach ?) по новой таблице и сопоставляя другое уникальное поле (есть, к счастью, такое) с полями в связанных таблицах, обновлять его значение?Можно. Но геморройно... java73как наиболее простым способом сделать объединение данных и обновить заново сгенерированные в новой таблице ID в связанных таблицах (которые тоже, кстати, будут объединяться). Сначала убедиться, что ВСЕ связи поддержаны внешними ключами с атрибутом ON UPDATE CASCADE. Обновить id во второй таблице значением t2.id+MAX(t1.id), затем обновить id в третьей таблице значением t3.id+MAX(t2.id). В результате дублирование id в таблицах устранено, и все референсные значения обновлены корректно. Можно сливать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.01.2019, 10:18 |
|
||
|
Миграция данных со старой схемы на новую
|
|||
|---|---|---|---|
|
#18+
Начал делать немного по-другому. При копировании старой таблицы в новую, его ID копируется в новое полe oldID. Затем в строки, где есть связь, вставляется новый ID по сопоставлению oldID и ссылки на него. В общем как-то примерно так: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. После миграции, естественно, все поля oldID во всех таблицах подлежат уничтожению. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.01.2019, 10:22 |
|
||
|
|

start [/forum/topic.php?fid=47&msg=39766878&tid=1829336]: |
0ms |
get settings: |
9ms |
get forum list: |
13ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
43ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
49ms |
get tp. blocked users: |
2ms |
| others: | 231ms |
| total: | 368ms |

| 0 / 0 |

Извините, этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
... ля, ля, ля ...