И как на уровне кода выявить "горячие" таблицы с учётом foreign связей по ним? Как ты себе это представляешь?

Ну тот кто проектировал базу знает что горячее, а что менее

Не вариант. Foreign связи первыми сломаются

Хотя тоже верно

Если этот проектировщик решит здоровенную базу по живому резать, то это хреновый проектировщик)

Например, у нас на работе дамп базы весит чуть больше 14 гигов. С учётом круглосуточного обращения к ней мигрировать её таким образом нельзя. А если бы и собрались, то заранее оповестили б всех клиентов, что в период с X по Y будут вестись работы, в течение которых выключение приложений, лок базы, миграция и т.д.
Вот так бы я поступил в случае необходимости миграции на другую СУБД.

У нас мускуль на борту. Недавно ребята мигрировали на другой сервер. Сделали по живой: на новом оформили SLAVE, на старом - MASTER. Запустили миграцию через бинлог, когда база стала готова, переключили все приложения на неё. Убрали SLAVE, заменив на MASTER, а старый сервер дропнули. Вот так мы перевозили базу практически без всяких потерь в течение рабочего дня на другой хостинг.

тут есть gener_id как выташить ид их категори типо $kino->gener_id['0']; так?

каст сделал?

что такое ксаст?)

$kino->gener_id['0']->cat_name

так делать?

@zmurf )

хрень делаешь

зачем ты  записал в json?

а как правильнее будет

связь сделать

почитай как связи в бд делать

типо через связь легче будет чем через json?

тут какой вариянт подходит один ко многим да? типо 1 кино может иметь много категори?