Scratch

я уже смирился что ты не неадекват (в каникулы много детей заходит)

Я тоже смирился с тем, что для вас вопросы сравнения производительности - это вопросы ваше личной веры в мощь сериализации :)

в общем их тест полное дерьмо, я уверен.

Давайте напишем свой тест по указанному примеру с заказами и товарами и расставим "точки над i"? Ну чтобы все было адекватно и без школоло. Хотя последний раз у меня были каникулы чуть больше 20 лет назад, но немного времени для такого тестирования у меня есть.

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

Сериализация будет работать быстрее для извлечения данных для одной единственной записи или до определенного порога, после которого JOIN будет быстрее. Программисты, которые писали оба приложения - не самые худшие. Второе приложение проигрывает в производительности именно в случае выборки больших объемов данных, то есть при достижении определенного числа записей, как и было сказано ранее.

оффтоп: я просто хотел скзаать что оба метода если влоб имеют недостатки, вот и все, ничего личного. маста хорошо подметил что можно одним внешним ключем решить эту проблему.

И я говорю то же самое :) Можно и ключем, просто выводить осмысленное информационное сообщение вместо сообщения о нарушении целостности (или не выводить никакого) удобнее, если делать запрос.

Например, если поставки товара X прекратились и надо уведомить заказчиков об этом. В случае хранения сериализованных данных вас ждут пляски с бубном… В первом варианте - простейший SELECT.

например глупая менеджер вместо кнопки "отклчить товар" нажала кнопку "удалить товар" и во всех заказах при join'e пошли позиции пиздой где присутствовал этот товар.

Ваш пример говорит о глупом программисте, а не о глупом менеджере. Проверку целостности данных для исключения появления товаров-"орфанов" в заказах никто не отменял, и, кстати, такая проверка опять-таки гораздо проще выполняется при хранении данных в несериализованном виде - простейший SELECT для проверки существование товара в заказах перед удалением и сообщение для глупого менеджера от умного программиста.

Сериализацию вполне уместно применять для полей, являющихся "описательными" - полей хранения каких-либо вспомогательных данных, извлекаемых для одной записи. Но хранить в сериализованном виде индексные поля выйдет себе дороже.

Могу кстати привести и пример реальных PHP приложений, где применяются 2 вышеуказанных подхода. CMS Joomla и популярные CCK K2 и ZOO. В первом элементы для создания приложений хранятся в классическом "реляционном" виде, во втором приложении - в виде сериализованных данных в XML. Сравнивались данные по производительности и, несмотря на бОльшее количество запросов к MySQL для получения нужной схемы данных, первый компонент работает быстрее, чем тот, в котором производится десериализация на лету. И по удобству схемы построения данных для дальнейшей разработки первый компонент явно лидирует: количество сторонних дополнений для классической схемы на порядки больше.

Классический вариант в виде таблицы id заказа - id товара лучше. Подумайте, например, над простой задачей - "вывести все заказы, где присутствует товар X". Например, если поставки товара X прекратились и надо уведомить заказчиков об этом. В случае хранения сериализованных данных вас ждут пляски с бубном… В первом варианте - простейший SELECT.

ну тут в принципе очень просто :)

mysqli_multi_query($connector, $check_session_query);
$i = 0; 
// Счетчик итераций. foreach недопустим, так как у вас первый запрос  и второй запрос возвращают
// разнородные данные: первый SELECT - дату,  второй SELECT - набор записей таблицы sessions
do {
    if ($result = mysqli_use_result($connector)) {
        $i++;
            $row = mysqli_fetch_assoc($result);
                if ($i == 2) { // Вторая итерация - ваш SELECT с данными
                    if ($row !== NULL) {
                        while ($row = $result->fetch_row()) {
                            printf("%s\n", $row[0]);
                        }
                    }
                }
        }
    mysqli_free_result($result);
} while (mysqli_next_result($connector));

По поводу выноса промежуточных операций (арифметики, как тут выразились) для формирования итогового запроса - вы все сделали правильно, Armageddance. Проблема видимо психологическая. SELECT, используемый для вычисления выражения и присвоения его переменной в MySQL создает очень мизерную нагрузку по сравнению с SELECT выборками из таблиц. Помимо этого пул запросов перед выполнением на сервере проходит прекомпиляцию и выполняется как один запрос и потому он эффективнее, чем серия простых запросов. Скорость "вычисления арифметики" прекомпилированным запросом на MySQL будет выше, чем его вычисление интерпретатором, то бишь средствами PHP. Это неоднократно проверено на относительно больших таблицах (от 1 млн.записей), другое дело, что выигрыш на небольших массивах данных будет мизерный. Но и подход "у меня не будет много записей, потому напишу как умею" - это первый шаг к индусскому коду :)