mayton2019

Типа можно накатить изменения и также безопасно откатить.

По поводу безопасного отката. Это на 99% зависит от SQL кода который вы напишете. Это никак не связано с фреймворком поддержки миграций. Берите какой угодно фреймворк. Например liquibase или flyway.

И даже в них если во время alter table rename column вы столкнетесь с активными сессиями в БД - то ваша транзакция переименования упадет и вы будете вручную решать ситуацию отката или наката.

Безопасность наката и отката также зависит от грамотности описания ваших чендж-сетов. Бывает так что в 1 чендж-сет запихивают 2 DDL команды и одна из них проходит а вторая не проходит и фреймворк повисает навсегда в клинче. Двигаться назад он не может т.к. Не был применен чендж-сет. И двигаться вперет тоже не может т.к. первая DDL команда уже выполнена и повторо ее вызывает ошибку типа "table/index already exists".

Выводы - грамотность описания чендж-сетов. И все.

Ваш фреймворк phinx выглядит ужасно с точки зрения кода. Как по мне он не делает главной задачи а именно - не является DSL для upgrade/rollback. Он - прибит гвоздями к PHP и следовательно его можно рассматривать только под углом вашего PHP-удобства. Удобен он вам? Используйте.

Но, как я понял, она про другое, про упаковку после удаления. А мне нужно, что бы просто листовые страницы B-дерева заполнялись полностью, как у ms sql с fill factor = 100. То есть, максимально плотное заполнение базы данных, когда идет просто построчная вставка.

Ты напомнил анекдот когда женщина приша к урологу и жалуется что у мужа дескыть "одно яичко ниже другого. Непорядочек.."

Вобщем перфекционизм хорош в меру. Если ты читал об организации индексов на основе B+Tree (практически везде) во всех DBMS, то ты должен был читать о том что среднее заполнение листовых блоков обычно равно 75% от размера блока. Это связано с возможностью оперативно делать insert новых ключей и значений. Если ты, используя какие-то утилиты специально выровнял заполнение блоков - то индес становится медленным для будущих вставок. Каждая вставка продуцирует операцию split (тяжелая операция) и пока не посплитятся все листы - перформанс будет плохой.

Ну во первых смысл неправильный. У тебя - взаимоисключающие предикаты. Поэтому надо использовать OR.
Уже написали выше про это.

Попробуй так. Должно быть быстрее.

SELECT * FROM data WHERE name LIKE "Иван%";

И построй индекс по name. А лидирующий метасимвол % лучше не ставить т.к. это отключает
возможность использования классическийх B-Tree индексов.

Если три части ФИО отсортировать как массив из 3 элементов - то будет одинаковая последовательность.
Вот так и искать можно.

OUTER JOIN позволяет выбрать даже те записи которые не сджойнились слева или справа.
В таком случае левая или правая таблица заполняется NULL значениями но все ключи
присуствуют в результирующей выборке.

DELETE * FROM products_vpn WHERE productsid = ?, amount = ?

Ты наверное - бывший программист на Prolog?
Что это за запятая там стоит?

Нужно создавать для каждой колонки свой индекс

Нет. Индекс создается под конкретный запрос. И то создание индекса должно быть доказуемо эффективным.
Делаешь семействое бенчмарков без индекса. Меряешь. Потом с индексом. И не забывай про эффект прогрева.

Если ты решил потратить всю "прокрастинацию" на индексы - то это bad way. Индексы занимают полезное место
на диске и в памяти и как верно заметили выше - еще и замедляют DML операции.

Погуглил, и нашёл что все единодушно говорят, что лучше БД. ОК. Понятно. Доводы убедительны. Но возникает такой вопрос.

Предположим, что у меня 5000 пользователей, у каждого по 100 постов, в каждом посте по 10000 символов. Размер всех постов получается 5 ГБ. Но это же огромная сумма! Хранить такое количество данных в БД как-то не очень. БД будет тормозить, всё это скажется на производительности и в конечном счёте это отразится на клиентах.

Какой же тип хранения мне всё-таки выбрать? БД или простые файлы?

Тут - мало входных данных. Во первых нужно собрать все кейсы работы с информацией.
Например: Пользователь создал пост. Пользователь отредактировал пост. Другие пользователи - проголосовали.
Пользователь удалил пост.

Далее - исходя из этого нужно создать модель постов. Определить какие режимы изоляции или блокировок нужны.

Откровенно говоря в наше время дизайн системы на 80% идет от хостинга и от того какие цены выставляет
хост провайдер на RDBMS и на Storage. Само хранилище может быть десятков видов. S3, Microsoft BLOB, GoogleCloud storage. И вот исходя из цен и из того какая формула биллинга - обычно и берут архитектуру.

Безкомпромиссные решения могут дорого стоить. Вот. Поэтому вопрос - где хранить данные распадается
на хозяйственный вопрос - а где покупаете хостинг и далее уже можно там как-то варьировать.

В вашем случае с постами я-бы сказал что S3 вполне себе справится. Я-бы хранил тело поста в S3 а прочую
информацию о статусе редактирования и голосованиях - в любой реляционной БД.

Если таблица постоянно растет - то должен быть какой-то ограничитель. Иначе будет рефрешится все медлненнее и медленнее.

А попробуй сделай так

create index name_idx on emails(name);

и повтори свой запрос еще разик.

В SQL обычно одинарные кавычки используются для строковых литералов.

DELETE from books WHERE us_books = 'слово' .....

Двойные там для других задач. Например для приведения идентификаторов к CASE-sensitive виду.- Типа "MyTable"

Как-то много текста у тебя написано. Обычно делают.
update users set money=money-sum where user_id=?