• Как организовать правильные запросы?

    Adamos
    @Adamos
    Даже без JOIN (мало ли, какие-то данные могут быть многострочными) совершенно необязательно городить циклы.
    Вы запросили статьи. Получили данные. Зачем сразу выводить? Соберите их пока в массив, попутно создавая массив id статей, авторов, чего там еще понадобится.
    Следующим номером сделайте один (!) запрос - SELECT author_name FROM authors WHERE author_id IN (у нас уже есть этот массив). Аналогичный запрос или два к таблице с комментариями - и все, больше вам базу дергать не требуется, и все данные для вывода получены.

    Глядишь, понемногу придет осознание, какую пользу приносит разделение логики и вывода...
    Ответ написан
    Комментировать
  • Как организовать правильные запросы?

    talgatbaltasov
    @talgatbaltasov
    Freelancer
    прочтите про join
    Ответ написан
    Комментировать
  • Нанимаю сотрудника/помощника. Как правильно поступить с деньгами и легализацией?

    kale
    @kale
    Самое главное, не выводите своего работника на прямой контакт с жирным заказчиком, доверию здесь нет места. Иначе скоро останетесь в стороне. Проверено жизнью..
    Ответ написан
    1 комментарий
  • Нанимаю сотрудника/помощника. Как правильно поступить с деньгами и легализацией?

    IonDen
    @IonDen
    JavaScript developer. IonDen.com
    PayPal в серую норм, если ваш коллега не резидент США или другой страны с суровыми законами.
    Ответ написан
    3 комментария
  • Каков must have для студии по разработке?

    banderos120
    @banderos120
    Играю на балалайке
    Когда-то начинали с товарищем делать сайтики, только я был "программистом", а он собирал заказы. Одни из ошибок, которые позволили загнуться нашему совместному предприятию (просуществовали мы почти 2 года) - это:
    - недостаточно опытный программист (это я), плюс, если брали помощников, то они были еще неопытнее меня.
    - не составлялся четкий план на разработку, проектирование проекта не проводилось, из-за чего по ходу дела возникали ситуации, которые можно было решить еще на этапе проектирования, но нет, приходилось тратить время уже во-время разработки. Как следствие этого - неожиданное увеличение сроков.
    - не было четких условий для заказчика, т.е. типовой договор был, но, например стоимость правок оговаривалась налету, некоторые заказчики округляли глаза и приходилось делать забеслпатно. Следствие чего заказчик был царь и бог и некоторые их долги по оплате не были отданы до сих пор.
    - желание сэкономить, нет, я понимаю, что экономить нужно, но не на том, что приносит тебе доход, по-этому дизайнеры были хреновые, помощники говеные и т.д. Из-за чего заказчик был не доволен, а срок разработки проекта очень сильно увеличивался.
    - заказы по сложности и требованиям несопоставимые со стоимостью, т.е. напарник брал сложные заказы за смешные деньги, сетуя на то, что город маленький (300 000 жителей) и никто платить не хочет, в итоге с созданием и доработками выплаты задерживались, следующие заказы брались , пока недоделаны предыдущие и получался ком, которые ничего хорошего не обещал.
    - ну и результатом всего этого стало огромное количество долгов и плохих отзывов.
    Ну вот такие были проблемы у студии "Рога и копыта" из двух человек, какие вспомнил ))
    *пы.сы. не знаю, зачем это написал, просто, что-то вспомнилось.
    Ответ написан
    5 комментариев
  • Структура данных для поиска подходящих CSS-правил

    Если учитывать что Вы не привязваетесь к DOM, то можно предположить что все возможныне css правила это бесконечное множество (конечно можно сделать его конечным с ограничениями на число элементов или длине строки правила). Теперь любой css или группу css или одно css правило можно представить как подмножество всех css правил. Как я понимаю Вы хотите сделать из подмножества группы css другое подмножество с меньшим или равным количесвом правил (иначе весь смысл теряется). Те Вы хотите для двух любых правил найти найти в лучшем случае одно, в худшем два правила. Тогда:

    a {...} a {...} можно преобразовать в a {...}

    a {...} div a {...} можно преобразовать в a {...} только в том случае если правила a имеют больший приоритет, например !important, в противном случае этого сделать нельзя тк данные правила определяют разные возможные подмножества.

    Я склоняюсь к тому что уменьшить количество правил практически нереально, тк они описывают разные подмножества. Когда правила опиывают одно подмножество, или более общее подмножество имеет больший приоритет, то некоторые правила можно упразднить.

    Теперь поиск. Для того чтобы определить элементы которому удовлетворяет правило, необходимо пройтись по всему дереву. Это достаточно интересный момент, тк некоторые css правила могут явно описывать элементы находящиеся внутри другого правила, например:

    .base .child и .base .child .node заведомо извесно что все .base .child .node элементы будут находиться внутри .base .child.

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

    Вариации поиска. Я вижу два основных варианта:
    1. берем правило, проходим по DOM, для каждого элемента вычисляя является ли правило DOM элемента подмножеством определенного правила и применяем его, переходим к сл правилу.
    2. берем DOM и начинаем проходить по нему, для элемента вычисляя является ли правило DOM элемента подмножеством определенного каждого правила и если да, то применяем его, переходи к сл элементу.

    На второй вариант очень хорошо ложится предложение с деревом подправил и вообще кажется более интересным ввиду того что требуется один обход DOM.
    Ответ написан
    2 комментария