Пользователь пока ничего не рассказал о себе

Наибольший вклад в теги

Все теги (17)

Лучшие ответы пользователя

Все ответы (23)
  • В чем основные отличия mySQL от Postgre?

    batyrmastyr
    @batyrmastyr
    Из простых преимуществ постгреса - многие запросы в нём отрабатывают шустрее, можно весьма гибко прописать ограничения на данные (если в поле "а" что-то есть, то в поле "б" может быть только "с"), даже крупному магазину может хватить настроек по-умолчанию при которых база довольствуется смешным объёмом памяти.

    Из недостатков по сравнению с Mysql - нет множеств (заменяется массивом перечислений), большая строгость работы (число или перечисление нельзя взять и сравнить со строкой "5 = '5'", нужно привести их к одному типу "5 = '5'::int" или " 5::text = '5'5 ", а ваша обёртка над базой может быть не готова к такому).

    В контексте nosql баз данных например вижу преимущества в быстродействии, например, причем на порядок.

    Увы, это преимущество скорее всего окажется мифом - сейчас как раз потихоньку выпиливаем MongoDB.
    Если говорить про MongoDB, то в моих задачах он работал либо не быстрее мускуля или постгреса при поиске, либо в разы (в 2 - 50 раз) медленнее при записи. При этом Монга жрала 1,5 гига памяти, мускуль - 300 Мб, а постгрес - меньше 15 Мб (да, меньше жалких пятнадцати мегабайт).
    Ответ написан
    3 комментария
  • Как грамотно использовать rem в адаптивной вёрстке?

    batyrmastyr
    @batyrmastyr
    базовый шрифт не 16px, а какие-нибудь 14.25px±50%

    За такое надо исправить должность на "дизагнира". Дробные пиксели все браузеры отображают как хотят: кто-то округлит до целых, кто-то до сотых, как у вас, а кто-то честно отрисует даже 14,674956954px. Добавьте субпиксельное сглаживание и получите кучу вопросов "а что у вас шрифт такой мыльный?".

    Реально ли пользователи подстраивают размер шрифта?

    Сейчас пользователи могут только всю страницу масштабировать. Особо не пользуются, только если со зрением (у пользователя или создателей сайта) проблема.

    Чего точно не стоит делать, так это смешивать пиксели и типографские пункты. Либо {font-size: 1em, line-height: 1.25em}, либо {font-size: 16px, line-height: 20px}. У нас сейчас решили использовать пиксели чтобы не думать, чему будут равны 1,4 пункта, особенно если кому-то приспичит сменить размер шрифта. Хотя лично я считаю допустимым при вёрстке в пикселях иногда использовать em для указания отступов, например, в :first-letter.
    Ответ написан
    4 комментария
  • Кому реально нужны правила по использованию cookie на сайте?

    batyrmastyr
    @batyrmastyr
    В ЕС такая же история, причем длится она дольше, чем в РФ.

    Так из-за ЕС эта фигня и началась. Принимавшие этот закон чиновники, видимо, считали, что пользователи предпочтут те сайты, где за ними не следят. Получилось как всегда.
    А наши делают так либо из-за выхода на европейский рынок, либо по глупости.
    Ответ написан
    Комментировать
  • Есть ли практическая польза от книги sicp?

    batyrmastyr
    @batyrmastyr
    каким боком нужна вся эта математика и алгоритмы во фронтенде?

    Многие инженерные специальности опираются на математику, как на фундамент. Одним из базовых навыков для программиста (который инженер, а не специально обученная обезьяна) является умение оценить вычислительную сложность программы и написать эффективный алгоритм. Из-за медлительности яваскрипта и операций с DOM, а также разбухания объёма клиентского кода вопрос эффективности стоит очень остро.
    Вместо sicp можно взять любую другую книгу развивающую мышление + дающую понимание «сколько эта операция будет стоит» - хоть «Искусство программирования» Кнута, хоть «Алгоритмы и структуры данных» Вирта, хоть «Структуры данных и алгоритмы» Ахо, Ульмана и Хопкрофта, хоть кого другого.

    Вот несколько примеров, что случается если не оценивать сложность, а то и вовсе «сперва кодить, потом думать»:
    24-ядерный CPU, а я не могу сдвинуть курсор,
    Один разработчик чуть не «сломал» пакетный менеджер NPM,
    Facebook и Google выпустили Yarn, новый менеджер п... (npm писали клинические дебилы - грузить десятки раз один и тот же пакет!),
    Ещё на новый год многие любят повесить на сайт падающий снег и почти у всех он отжирает целое ядро процессора, в каждой открытой вкладке, Карл! 8 вкладок и у тебя висит даже Core i7. Но если настольные компы просто подвисают, то ноутбуки и телефоны ещё и аккумы разряжают со страшной скоростью.
    Ответ написан
    Комментировать
  • Как правильно работать с большим количеством данных?

    batyrmastyr
    @batyrmastyr
    - получение данных об общем количестве записей для построения пагинации, это SELECT count(id)

    1. count(*), а не count(id)
    2. если вас не сильно интересует абсолютно точное значение для миллионов результатов, то делаете оценку количества, начать проще с EXPLAIN <текст запроса> вы можете получить оценку количества результатов. Мы для себя решили, что если по оценке меньше 50 000 строк, то вслед за этим делаем обычный SELECT count(*) для получения точного количества.
    Потом дергается запрос для получения данных на экспорт

    1. Пожалуй, вам от этого нужно избавляться в первую очередь. Нажал человек на кнопку "экспортировать" - экспортируете, а до этого и дёргаться нет смысла. Фильтры можно получить либо при клике, либо из заголовка referer
    2. Если вам нужно абсолютно все данные, то ставите задание на экспорт в очередь и выполняете его в отдельном процессе, сохраняете в файл. Для пользователя рисуете прогресс выполнения и выводите его в нажатую пользователем кнопку, хотя можно тупо на отдельной странице выводить список "заказанных" выгрузок и ссылки на скачивание.
    Запросы на каждый выпадающий список в фильтрах - SELECT distinct field_name

    Можно с какой-то периодичностью выгружать выхлоп таких запросов в материализованное представление / справочную таблицу / ENUM. Для обновления таких справочников "в реальном времени" можно повесить триггер на вставку в основную таблицу который будет делать INSERT INTO dictionary (value, column_oid) ON CONFLICT / ALTER TYPE ADD VALUE IF NOT EXISTS
    После чего в основной таблице заводите рядом поле под идентификатор в справочнике и индексируете уже его.
    Запрос при фильтрации и сортировке - SELECT * FROM some_table WHERE field_name LIKE '%value%'

    1. если у вас значения длинные (от 8 - 10 символов), то стоит попробовать триграммные индексы. Но на коротких значениях они могут замедлить поиск раза в полтора-два.
    2. Полнотекстовый поиск. В частности есть поиск лексемы по префиксу ts_tsquery('сло:*') (быстро найдёт и "слово" и "словарь", но не найдёт "однословное")
    3. Для полей по которым вы сделаете словари лучше делать поиск через словарь SELECT * FROM table WHERE column_dictionary_id IN (SELECT id FROM dictionary WHERE value LIKE '%текст%'). В словаре у вас наверняка на порядок - три меньше значений, а несколько сотен или тысяч значений в IN постгрес нормально пережуёт.
    Полей много, разные даты, guid, названия проектов, данные из поля типа json, цены.

    Активнее используйте функциональные и частичные индексы.
    Например, у нас есть кадастровые номера. Триграммный индекс по ним весит 56 мбайт, а BTREE по номерам урезанным до кадастровых кварталов - 15 мбайт, в поиске к "cadastre_id LIKE '11:22:333333:1%'" добавился "AND to_quarter(cadastre_id) = '11:22:333333'", но сам поиск получается на порядок быстрее (~5 мсек вместо 50 - 70).
    Главное не забывайте о стоимости этих самых функций - индекс по to_quarter может строиться всего в 1,5 раза дольше нефункционального, если делать LEFT(cadastre, -(position(':' IN reverse(cadastre))), а может и в 100 раз, если использовать регулярку.
    На все индексы не поставишь, тем более что один индекс может добавить гигов 5-10 к весу.

    Если ещё не обновились, то обновляйтесь на 13-ю версию, там размер BTREE индексов уменьшили в 3 раза. Ну и посмотрите, возможно вам где-то нужны GIST, GIN или BRIN индексы.
    Ответ написан
    2 комментария