• Как собрать массив массивов, имея массивы ключей, ключей и значений вложенных массивов?

    @Vitsliputsli
    Ипатьев,
    Это не то замедление, о котором вообще стоит говорить.
    Вы его увидите только на цикле, который вообще нихчего не делает. Во всех остальных случаях вы его с электронным микроскопом не увидите.

    Есть такое выражение "экономить на спичках", когда мы начинаем оптимизировать то, что и так работает быстро, путем усложнения кода или других жертв. Здесь не тот случай, здесь просто ошибка, т.к. для обхода массива нужно использовать итератор.

    Бессмысленность строчки $result[$key] = []; - это для вас "тайное знание"? :)

    Да, не вижу как можно без нее обойтись. Покажите?
    Написано
  • Как собрать массив массивов, имея массивы ключей, ключей и значений вложенных массивов?

    @Vitsliputsli
    Ипатьев,

    ну это сказки же.
    и у вас тоже ненужные присвоения (:

    Foreach это итератор, он перебирает массив по ссылкам двусвязного списка, в for обращаемся по ключу (конкретно в этом коде, можно было бы и в цикл for добавить итератор, но тогда он еще более бесмыссленым становится), а значит идти придется через хеш-таблицу, а не сразу по прямой ссылке. Лишнее действие будет замедлять работу.
    Если код можно еще улучшить, так покажите, а не кичитесь "тайным знанием".
    Написано
  • Как сгруппировать значения в массиве и получить среднее арифметическое для определенного поля?

    @Vitsliputsli
    Почти то же самое, но без 2х обходов массива:
    $result = [];
    foreach ($arr as $obj) {
        $idPublic = $obj['id_public'];
        if (isset($result[$idPublic])) {
            $result[$idPublic]['number'] = ($result[$idPublic]['number']+$obj['number'])/2;
        } else {
    	$result[$idPublic] = [
    		'id_public' => $idPublic,
    		'number' => $obj['number'],
    	];
        }
    }


    Если нужно просто среднее по каждому (без структуры), то можно еще проще:
    $result = [];
    foreach ($arr as $obj) {
        $idPublic = $obj['id_public'];
        if (isset($result[$idPublic])) {
            $result[$idPublic] = ($result[$idPublic]+$obj['number'])/2;
        } else {
    	$result[$idPublic] = $obj['number'];
        }
    }


    Если исходный массив отсортирован по id_public, то можно избавиться от множественных обращений к массиву по ключу.
    Написано
  • Как собрать массив массивов, имея массивы ключей, ключей и значений вложенных массивов?

    @Vitsliputsli
    danilapon, в вашем коде есть ненужные присвоения, выкинув их можно записать так:
    foreach ($input as $i => $key) {
        $result[$key] = [];
        foreach ($params as $j => $param) {
            $result[$key][$param] = $arrays[$j][$i];
        }
    }

    Добавлю, foreach не только удобнее, он и более производительный при обходе массива, чем for.
    Написано
  • Как отобразить первичный ключ состоящий из вторичных?

    @Vitsliputsli
    Kotorkovsciy, ваше отношение это Device к Event. Здесь видим только часть реализации этого отношения - техническую таблицу, а для определения соответствия нормальной форме нужно все отношение.
    Если предполагаем, что больше ничего нет, а 2 поля это натуральные ключи, то очевидно соответствие 1 форме, а так как нет неключевых атрибутов, то и 2, и 3.
    Написано
  • Как перезагружать страницу при появлении определённого элемента?

    @Vitsliputsli
    Нужно разделять логику и отображение. Поэтому пркручивать нужно не к "затемнению экрана", а к логике его вызывающей, которая определила, что данные устарели.
    Написано
  • Можно ли запустить WebSocket по переходу на страницу?

    @Vitsliputsli
    Временный он потому что он действует пока открыта страница в браузере или пока есть соединение в самим сокетом.

    Вы описываете решение, а не задачу. А про задачу спрашивают, потому что зная ее, возможно, решать надо другим способом. Так, я не вижу причин, почему бы ws-сокет демону не работать постоянно, на то он и демон.
    Выглядит очень странно, но в чем проблема? Пришел запрос по http - запускаете демона, демон видит, что все отключились - закрывается.
    Дополнительно, нужно посмотреть как настроить systemd unit, чтобы он перезапускался только при ошибке. И если клиент отвалился некорректно, то контролировать это, либо забить, если быстрая реакция не важна.
    Написано
  • Как правильно задать запрос UPDATE где название столбца переменная?

    @Vitsliputsli
    Ипатьев, не любое, но вы сделали именно так. Согласен, спорить с тем, кто на каждый вопрос отвечает "я всегда прав, и потому не буду даже ничего аргуметировать" бесполезно.
    Аргументы "это все говнокод" и "вы бредите" вовсе не аргументы. Назовите вашу схему хоть "зеленым горошком", но аргументируйте почем она в работе лучше, а все остальные плохие. Пока ваши утверждения, выглядят как гадания с помощью хрустального шара. Уже много раз писал, не зная как данные будут использоваться, что-либо утверждать наверняка беспочвенно. А спорю, потому что, действительно, мог чтото упустить, чего то не знать, иногда так и узнаю новое.
    Написано
  • Как правильно задать запрос UPDATE где название столбца переменная?

    @Vitsliputsli
    Какую нормальную форму нарушает текущая реализация?
    То, что вы предлагаете не нормализация, а переход к EAV, которая применяется при большой вариативности атрибутов, но небольшом их кол-ве для каждой сущности.
    Когда необходим поиск по разным столбцам таблицы берут и создают запросы динамически с помощью какого-либо билдера, т.е. "задают имя столбца через переменную". Никто ради этого не переводит таблицу в формат EAV или похожий.
    Пока неизвестны все варианты работы с данными однозначно зявить что нужна только какая-то конкретная схема нельзя. Так для EAV адресация будет работать медленней из-за составного ключа, объем хранимых данных также может вырасти, а не уменьшиться, а если окажется, что автору нужно выводить аттрибуты как таблицу, то привет pivot (т.е. столько join, сколько атрибутов будем выводить).
    Т.е. если и нужна EAV, то точно не по указанным причинам.
    Написано
  • Как правильно задать запрос UPDATE где название столбца переменная?

    @Vitsliputsli
    Ипатьев, еще раз, я привел вариант как это сделать несколькими простыми строчками на php, и вы его видели. И все они касаются только маппинга из входных данных в текщее хранилище, то что вы не делаете маппинг, а используете входные данные как есть, уменьшает код, но не факт, что в будущем это не выйдет боком. Ну нельзя выбирать схему хранения, только потому, что захотелось сэкономить на маппинге.
    Написано
  • Как правильно задать запрос UPDATE где название столбца переменная?

    @Vitsliputsli
    Ипатьев,
    нормализация - это серебряная пуля и панацея. Один из ключевых принципов архитектуры.
    И не надо ставить денормализацию на одну доску с ней. Это не принцип проектирования баз данных, а компромисс, который никогда не закладывается исходно, а добавляется сильно позже, когда (если) возникают проблемы с производительностью.

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

    Чем схема плоха, я наглядно показал в своем ответе - при нормальной схеме - когда номер счетчика уходит в условие, где он и должен быть - сразу пропадает ВЕСЬ этот говнокод, и делается простой запрос апдейт.

    А где говнокод? Динамический SQL? Да он присутствует практически в любом проекте, и то, что у автора он собирается не так элегантно как в популярном фреймворке, ни разу не говнокод. Как сделать боле читабельным код на php и убрать гонку я показал, но схема БД здесь не при чем. Да и называть любой не свой код говнокодом, это так себе...
    И вы ничего не показали, ваш update ничем не лучше update с динамическим SQL. Пока мы больше не узнаем о том, как еще будут работать с этими данными (или как они соотносятся) бессмысленно говорить о "плохих" схемах. Про производительность и место для хранения вообще молчу, я так понял на это забиваем, но все же какую нормальную форму нарушает текущая схема?
    Написано
  • Как правильно задать запрос UPDATE где название столбца переменная?

    @Vitsliputsli
    Ипатьев, ага, проглядел этот момент. Очевидно, что в случае неопределенного кол-ва параметров не получится создать неопределенное кол-во столбцов. Согласен, надо было на это обратить внимание.
    В общем случае, нормализация не панацея и не серебрянная пуля, а денормализация наш повседневный инструмент. Специализация может оказаться более важной, чем универсализация. Да и с данными там непонятно, там вполне может оказаться, что это все же один и тот же объект с вполне определенными свойствами, т.к. автор не сознается об истинных данных, и явно заменяет их примерами из головы, что при этом потерялось неизвестно.
    И, повторюсь, проектировать бд нужно исходя из того, как ей будут пользоваться, а не только исходя из данных.
    И, кстати, чем схема то плохая? Если параметров 3.
    Написано
  • Как правильно задать запрос UPDATE где название столбца переменная?

    @Vitsliputsli
    Ипатьев, если плодить то будет печально, действительно не указал на это. Но, насколько я понял, они у автора не плодятся, а есть объект с 3 свойствами. Если есть подозрение, что будут плодиться, то очевидно, что существующий вариант не лучший.
    В любом случае, выбрать наилучший вариант невозможно, не зная все о данных и вариантов обращений к ним.
    Написано
  • Как правильно задать запрос UPDATE где название столбца переменная?

    @Vitsliputsli
    Михаил Смирнов, текущая схема вполне себе неплохая, но с точки зрения реляционной модели нужно сделать составной ключ, т.е. таблица будет выглядеть примерно так:
    id_part1 id_part2 count
    21 1 3
    21 2 4
    здесь первичный ключ составной id_part1 + id_part2.
    В принципе, не так принципиально какой вариант выбрать, если только у вас нет повышенных требований к производительности. А если есть, то нужно исходить из запросов которые вы будете делать, а не только от хранимых данных.
    Написано
  • Как правильно задать запрос UPDATE где название столбца переменная?

    @Vitsliputsli
    Ипатьев, он идентичен только функционально. К функциональности вопросов нет, но у кода есть не только функциональность, есть такая штука как читаемость, и это не вкусовщина.
    Представьте что вы не читали задание и не знаете что нужно сделать и посмотрите на запрос:
    UPDATE `list` 
            SET count1 = CASE WHEN id = ? AND ? = 1 THEN count1 - ? ELSE count1 END,
                count2 = CASE WHEN id = ? AND ? = 2 THEN count2 - ? ELSE count2 END,
                count3 = CASE WHEN id = ? AND ? = 3 THEN count3 - ? ELSE count3 END
            WHERE id = ?

    сколько времени уйдет, чтобы понять что он делает? Подскажу - бесконечность. Не зная, что конкретно подставляем вместо вопросиков, что он делает неизвестно. Давайте улучшим, добавим именованые параметры:
    UPDATE `list` 
            SET count1 = CASE WHEN id = :id_part1 AND :id_part2 = 1 THEN count1 - :count ELSE count1 END,
                count2 = CASE WHEN id = :id_part1 AND :id_part2 = 2 THEN count2 - :count ELSE count2 END,
                count3 = CASE WHEN id = :id_part1 AND :id_part2 = 3 THEN count3 - :count ELSE count3 END
            WHERE id = :id_part1

    Уже лучше, теперь смотря только на запрос можно понять, что он делает, не спервого взгляда, но можно.
    Но, лучше ли читаемость, чем если бы мы это сделали на php? Сравним:
    const COLUMNS = [
        1 => 'column1',
        2 => 'column2',
        3 => 'column3',
    ];
    $column = COLUMNS[$id[1]];

    UPDATE `list`  SET $column = $column - :count WHERE `id` = :id_part1

    В этом решении только простые конструкции и все понятно с первого взгляда. На SQL, к сожалению, так не сделаешь, в нем очень часто получаются монструозные конструкции.

    И это никак не вкусовщина, если вы собираетесь сопровождать проект, то лучшая читаемость необходимость.
    Написано
  • Как правильно задать запрос UPDATE где название столбца переменная?

    @Vitsliputsli
    Анастасия Foxman, вы и на работе на комментарии при ревью так реагируете? Не воспринимайте это лично, это претензия к коду, а не к вам, только так можно улучшать код и свои навыки. Свой вариант я написал в комментариях, можете также сделать ревью для него.
    Комментарии это хорошо, но лучше, когда они не нужны, и все понятно из кода.
    Написано
  • Как правильно задать запрос UPDATE где название столбца переменная?

    @Vitsliputsli
    А теперь представьте, что вы смотрите на этот код через полгода-год, или вообще другой человек смотрит, сколько времени уйдет на то, чтобы понять что тут творится? И что этот человек подумает, когда поймет, что это на самом деле просто UPDATE `list` SET $column = ? WHERE `id` = ?
    Написано
  • Как правильно задать запрос UPDATE где название столбца переменная?

    @Vitsliputsli
    Для защиты от SQL-инъекций достаточно:
    $column = 'count' . (int)$columnNumber;
    Хотя для такой подстановки, если столбцов вменяемое кол-во, я бы лучше сделал так:
    const COLUMNS = [
        1 => 'column1',
        2 => 'column2',
        3 => 'column3',
    ];
    if (!isset(COLUMNS[$id])) {
        throw new \InvalidColumnException();
    }
    $column = COLUMNS[$id];

    Все таки это сопоставление, и вычисление может быть не лучший вариант, а динамически составляемое имя столбца очень портит читаемость.

    Но, если делать рефакторинг, то я бы в первую очередь обратил бы внимание, что за странные id с тире внутри и вообще зачем динамические столбцы.
    Написано
  • Лег сервер, нагрузка CPU 100%. Что делать?

    @Vitsliputsli
    Дмитрий Сериков,

    Я не админ, так понимаю лежит сервер БД

    Где вы это увидели? По процу на нем нагрузка 0. Отсортируйете по процу ваш htop, чтобы увидеть, что реально грузит проц.
    Написано
  • Можно ли всем строковым полям задавать тип TEXT и повлияет ли это сильно на производительность?

    @Vitsliputsli
    Сергей Соловьев, перепроверил, должен исправиться, в PostgreSQL тип char реализован по-мудацки, поэтому в этой СУБД его действительно лучше не использовать. Так что вы правильно написали, а мой пример некорректен для PostgreSQL.
    Написано