Это ни плохо и ни хорошо. Просто сейчас так модно - БД просто хранилище данных, а логика вся на сервере приложений.
res2001: Не совсем. Точнее совсем не из-за моды.
БД, в отличии от бекенда, масштабируется сложнее.
Поэтому вынос логики вычислений из БД достаточно логичен.
В php в общем случае вы даже с http не всегда будете работать на его уровне.
Фреймворк, кстати конкретно Symfony не рекомендую, она мешает и усложняет обучение.
Для совсем базовой вещи лучше ZF1
Именно первый это не опечатка.
Его писали достаточно академично по MVC.
Но вот в работе его лучше не использовать.
Отдельно потрогать микрофреймворки (Zend Expressive, Slim, Lumen, Silex) и средства для работы/проектирования апи (Apigility, Swagger, Apiary)
Еще что-то из работы с БД (query builder, active record, table gateway, row gateway, data mapper)
Тут выбор больше. Для Active Record это и Yii, и Eloquent из Laravel.
Table и row gateway можно посмотреть в зенде, data mapper в Doctrine и тоже в зенде (гидраторы в частности)
Я точно знаю что сначала залить данные, а потом создать индекс это быстрее.
Чем если создать индекс, а потом заливать данные.
Схема с:
Бекграунд переносом данных в копию таблицы.
Вычислением дельты накопившейся за время переноса.
Добавлением дельты в копию.
Переименование оригинальной таблицы в бекап, а копии в оригинальную.
Создает практически нулевое время простоя. Для слабо и средненагруженных систем.
Ни о чем.
Железо, конечно, старовато, но должно тянуть при правильном приложении.
В худшем из случаев вы включили индексы и тупо льете данные в БД. Это может быть очень долго.
3. При использовании pt-online-schema-change ясное дело, что в новую таблицу ничего не пишется и ничего из этой таблицы не читается.
Выполните этот сценарий руками.
pt-online-schema-change works by creating an empty copy of the table to alter, modifying it as desired, and then copying rows from the original table into the new table. When the copy is complete, it moves away the original table and replaces it with the new one. By default, it also drops the original table.
С одним уточнением.
Создаете таблицу (без индексов)
Заливаете данные.
Создаете индексы.
Переименовываете таблицу.
А у вас есть? Если нет, то откуда вы знаете, что он разрулит.
А у меня как ни странно есть. Потому что проекты, которые я вел, держали нагрузку 2-7 млн посетителей (а не просмотров) в сутки.
И БД была порядка 150Гб.
romalu: разрулит он путем наличия знаний, которых у вас просто нет.
Вы задавая вопрос не описали окружение.
Что за железо?
Какая нагрузка в это время на сервер?
Есть ли запись/чтение в таблицу которую меняете?
Отключали ли индексы перед тем как заливать данные в таблицу?
Вы знаете?
Вы меня сейчас очень сильно расстроили.
Вы серьёзно полагаете, что и браузер и операционная система появляются в компьютере путем непорочного зачатия?
На целевой машине, за которой ведётся мониторинг, ОБЯЗАНЫ стоять средства предоставляющие этот функционал.
Как один из вариантов это VNC.
А вот на машинах с которых вы хотите наблюдать, это можно делать через браузер. Насколько я помню такие решения имеются