На каждую таблицу будет заводиться индекс PK, если количество записей будет одинаковое (в смысле на каждое значение PK будет по одной записи в каждой таблице) - будет хуже, так как размер индекса у каждой таблице растет с ростом количества записей в ней, и много таблиц - много по факту отдинаковых индексов (но для разных таблиц он хранится), поэтому разделять по мелким узким таблицам имеет смысл только для разряженных данных, когда записи появляются только при наличии данных, причем чем больше таких отдельных таблиц тем больше должна быть 'разряженность' данных, чтобы это имело смысл.
Так как объем ПЗУ значительно выше (при той же стоимости) чем ОЗУ (а требования к ней таковы что индексы желательны влезать в нее, хотя бы для оперативных запросов) то лучше забить на оптимизацию по занимаемому месту данными, чем увеличить кратно требования для оперативного хранения индексов.
Поэтому - не дроби на большое количество таблиц, пусть будет меньше таблиц с большим количеством полей, но без фанатизма, если видишь что появляется куча условий not null когда как для нескольких таблиц это отрабатывается inner join, то тогда да (not exists лучше чем is null).
p.s. в догонку про сериализацию данных в одно поле, когда одно поле БД хранит сразу несколько значений - это оправдано и даже рекомендуется, если эти данные не имеют смысл по отдельности, красивый пример ip-адрес и порт как настройки подключения - суть одни данные, и нет никакого смысла разделять их на разные поля базы, за исключением случаев когда возможно потребуется активная аналитика по отдельному полю (например по ip адресу) - 'активная' тут это значит нужно строить индексы и делать частые запросы а не разовый full scan бакэндом.
Дробление данных на большое количество полей - повышает нагрузку на бакэнд (спорное утверждение, бывает наоборот, но зачастую да), правда для тех разработчиков, где такая оптимизация имеет смысл, такими вопросами не задаются, нужны действительно большие нагрузки.
Средний
