Да, только в результате мы получим количество записей равное количеству связей с авторамито есть те же яйца, вид сбоку. Только делать будете не 1 запрос, а 2. Вы все равно получаете все book_author>authors ограниченные через book_id. Количество записей будет одинаковым, точнее в вашем случае даже на 1 больше.
придётся дальше агрегироватьЗачем? Да, в каждой строке будет дублироваться книга (что вообще пофиг), но это будет 1 запрос и 1 массив, а не 2. Практической разницы около 0.
само поле fieldset может содержать до 200 таких категорий указанных через запятуюЖееесть, разработчик сам ушел, или его выпнули без выходного пособия?
Напиши продукт в конце-концов.Писать то тебе можно? Вот и пиши, когда будет вариант устроиться куда-то, на руках уже будет какой-никакой готовый пример того что ты умеешь.
точной информации по распределению нагрузки к сожалению нетЭто у вас ее нет, у админа есть лог реквестов к вебсерверу, исходя из которого легко считается рпс.
считаю, что так правильнее.Товарищ Прокруст, перелогиньтесь...
Спасибо за ответ, но ваше решение не помогло.Это не решение, это надо было добавить к вашим правилам, нижняя строчка в коде просто для ориентира куда добавлять. Код у вас относительно безопасный, но при смене папки со стилями скорее всего будете иметь проблемы...
если всё настолько сложно, значит очень вряд ли использовалась эта уязвимостькак раз наоборот, если все так сложно что многие разработчики забивали на разбор того как это работает, значит это точка слабого кода и в нее при желании залезет кто-то не особо ленивый и охочий до чужих данных. Тут уже действует принцип неуловимого Джо в плане ожидания взлома.
Не буду приводить более простые объяснения "на пальцах" с других сайтов, но в основном большинство статей пишет о замедлении вставки при увеличении размера таблиц. Возможно есть какие-то конкретные материалы говорящие о том что вставка не замедляется с ростом объема таблицы, но я на них не наткнулся.