1. PHP / Говнокод #17067

    +156

    1. 1
    2. 2
    3. 3
    4. 4
    5. 5
    6. 6
    7. 7
    8. 8
    // где то: 
    $_SESSION['type_school'] = $db->query("SELECT * FROM ou_type ",array(),'kassoc');
    
    // а потом:
    $smarty->assign('type_school',$_SESSION['type_school']);
    
    //и в шаблоне:
    <td>{$type_school[$v.base_type].type_name}</td>

    $v.base_type - тоже результат запроса. Left/Right/Inner Join - не, не слышал...

    А потом: чёта проект тормозит...
    Я так подозреваю кто то таким методом оптимизацию и кеширование сделал, ну чтобы бд лишний раз не грузить.. Не, ну, а чё, зачем каждый раз базу данных мучить при открытии одной! странички со списком *****, давайте одну таблицу-справочник из бд откопируем каждому пользователю в его сессию отдельно и будем читать его при каждом session_start даже если на текущей странице нам этот справочник не нужен.

    Запостил: vGhost, 05 Ноября 2014

    Комментарии (12) RSS

    • Главное забыл, внимание: $type_school[$v.base_type] ! Связь между таблицами организована по индексу в PHP массиве при определённой (дефолтной) сортировке выборки из mysql.
      Ответить
    • А потом взрыв случается в папочке /tmp/. :)

      В некоторых средах (jvm, clr) активно используется прием: считать при старте приложения справочник в память и юзать оттуда. Но во-первых там оно все таки хранится не в сессии, а в памяти, доступной отовсюду. Во-вторых в PHP так сделать нельзя (точнее говоря ЛЕГКО нельзя).

      Ну и наконец этот код вообще не имеет смысла так как БД при правильной настройке и там сохранит данные этой таблицы в кеше и будет брать их из памяти. Так что если только БД не находится на другом конце земного шара и не соеденина с вами по V34, то смысла в таком кеше нет.
      Ответить
      • Ну так сессии можно хранить и не в папочке /tmp/, а, например,... в базе.
        Ответить
        • > например,... в базе.
          Ну да, в каком-нибудь шустром мемкешеде. Тогда еще имеет смысл.
          Ответить
          • Угу, представляете сколько памяти надо будет мемкешу, если у каждого пользователя и гостя в сессии будет одна и та же копия таблички из бд? Это блин я не знаю как вообще могла придти в голову такая идея реализации...
            Ответить
            • Ну я не про этот случай, а про нормальное использование сессий.

              А таблички целиком в сессии кешировать - в любом случае ССЗБ ;)
              Ответить
          • тогда уж лучше взять какую-нить JVM, и хранить все в куче, а не во внешнем key-value хранилище)
            Ответить
            • Имхо, тут палка о двух концах.

              Если это кеш тупой статической таблички - запросто. Всё будет нормально.

              А вот если этих jvm'ов десяток на разных компах (масштабирование, все дела), а данные надо как-то синхронизировать между разными инстансами (а для сессий как раз таки надо) - тут только субд или мемкешед.

              Ну либо привязывать сессию к конкретному инстансу, что тоже не всегда хорошо.
              Ответить
              • Да, если у Вас 15 серверов и фиг знает на какой попадет следующий запрос то тогда и правда мемкеш.

                Хотя я видел привязки по JSESSIONID
                Ответить
                • Ну с привязкой трабла есть: нода внезапно остановилась - всех юзеров, которые к ней были привязаны, выкинуло на мороз, и все сессионные данные потерялись (а они всяко были, иначе зачем привязка?).
                  Ответить
                  • Ну а так сломался центральный мемкеш и на мороз отправились все Васьки.

                    Правда мемкеш тоже может жить в облаке и являться толпой серверов
                    Ответить
        • брать из базы и хранить в базе
          Ответить

    Добавить комментарий