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

Если ваши данные неструктурированы или недостаточно хорошо структурированы, то преимущество варианта NOSQL очевидно, но если вы работаете со структурированными данными и/или будете выполнять много запросов, то вам лучше использовать SQL для обеспечения производительности, надежности и, возможно, соответствия нормативным требованиям.

Даже самый простой SQL запрос можно выполнить по-разному. Но из всех вариантов СУБД нужно выбрать оптимальный, как же это сделать? Неужели придётся перебрать все возможные варианты? Давайте разбираться.

Point in Time Recovery (PiTR) — это восстановление базы данных на какой‑то конкретный момент времени (с точностью до секунд или до конкретной транзакции).

PiTR невероятно полезен для восстановления базы данных после того, как «случилось непоправимое». Если достаточно точно выбрать точку на которую восстанавливать базу, то можно восстановить базу данных практически без потери данных.

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

В настоящее время часто встречается задача - на карте расположено множество точек  и необходимо выделить их подмножество (отфильтровать) по критерию расстояния  от некоторой “особой” точки. В качестве примеров укажем сайты маркетплейсов, где точки пункты выдачи, в сетевых компаниях это офисы на карте, логистические компании отслеживают передвижение транспортных средств, операторы такси находят на карте ближайшие автомобили и можно перечислить еще много областей применения. При кажущейся простоте постановки задачи её решение требует значительных ресурсов, так как запросы к базе данных, как правило, очень тяжелые. Здесь на примере задачи ‘Пункты выдачи’ с фильтрацией по расстоянию (радиусу) от накопительного узла товаров показывается как можно сократить количество обработанных строк в запросе. Реализация задачи на БД mySQL.

Координаты исходной точки могут быть получены несколькими способами, первый если устройство пользователя оборудовано GPS и пользователь разрешил передачу своих координат, то мы получаем координаты пользователя без затруднений, второй способ менее точный мы получаем координаты пользователя из его IP, для этого используется библиотека maxmind.

В БД mySQL 5.7 появилась встроенная функция ST_Distance_Sphere для расчета (евклидово) расстояния между двумя точками. Данная функция принимает широту и долготу двух точек, а возвращает расстояние между ними в метрах, далее мы производим сравнение с критической величиной радиуса и определяем попадает ли данная точка в круг  с этим радиусом.

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

Как выявить и отладить такие проблемы? В этой статье будет показано решение наиболее распространённых проблем с производительностью БД, вызванных неправильной индексацией. Примеры будут приведены для Postgres, MySQL и SQLite.

Привет! В статье поделюсь, как инструмент автоматического рефакторинга Rector помогает обуздать легаси и автоматизировать обновление PHP проектов и пакетов, чтобы процесс проходил эффективнее и малой кровью. 

Статья написана на основе доклада с PHP Russia 2022.

Привет! Меня зовут Наташа Калачева. Я Frontend-разработчик в компании AGIMA. Vue — один из самых популярных фреймворков JS, его используют для разработки SPA и PWA. А его главные плюсы — это понятная, четкая документация, готовая структура и низкий порог входа.

Тем не менее, Frontend сегодня — это сложные приложения, которые содержат не только красивые элементы интерфейса, но и большую часть логики и функциональности всего продукта. Это требует от нас тщательного планирования и организации проекта, чтобы сделать его масштабируемым и простым.

В этой статье поделюсь правилами, которых придерживаюсь в работе и которые помогают упростить поддержку и расширение приложения. Мы рассмотрим, как организовать хранение компонентов, стилей и плагинов, когда использовать стор и полезные функции Vue.

Следуя этим рекомендациям, вы сможете создавать более эффективные проекты.

Доброго всем дня!

Хочу рассказать о своём практическом опыте реализации взаимодействия между процессами в среде Linux в условиях, когда вычислительных ресурсов существенно не хватает. По условию, один из процессов написан на C++, второй на PHP, потому дополнительно мы рассмотрим доступность соответствующих API из PHP а также варианты действий в случае, когда для нужного API PHP-обёртка отсутствует.

Ещё одна статья на избитую тему? Да! Потому что за два часа поиска не нашёл ни одной, по которой можно было пройтись от и до и получить работающее окружение.

Шагов, на самом деле, немного, все очень простые, нужно лишь...

Непрерывная интеграция (CI, англ. Continuous Integration) — это практика разработки программного обеспечения, которая заключается в выполнении частых автоматизированных сборок проекта для скорейшего выявления и решения интеграционных проблем. Целей у непрерывной интеграции две:

Привет! В декабре вновь прошел опрос русскоязычного PHP-сообщества. Помогали составлять его и распространять ребята, которые развивают городские и региональные PHP-комьюнити, а также руководят каналами и подкастами про PHP.

Удалось собрать 1215 ответов. Расспросили сообщество, на какой версии PHP сидят в командах, какой фреймворк выбирают для рабочих, а какой для личных проектов, многие ли посматривают на Go. И не только.

- Итоги 2021

- Итоги 2020

Этот дайджест я планировала выпустить в пятницу. В попытках сделать заголовок чуть интереснее, я забила в переводчик «говорить по-китайски», он мне выдал 说中文. По привычке проверила перевод в обе стороны, вроде всё адекватно. «А вдруг не так и китаисты с Хабра меня поправят?», — подумала я и полезла за фактчекингом, в ходе которого выяснила, что есть 汉语 — китайский устный и 中文 — китайский письменный, но 汉语 мало используется в повседневной речи и больше в академической среде, а ещё есть ультрапросторечной 中国话. И вообще версия 中文 выжила другие, потому что в официальных документах и буклетах китайский язык обозначается именно так. Далее я погрузилась в чтение статей про иероглифы, символику баланса и центра мира, многонациональный Китай… Короче, глубокая ночь воскресенья, я доделываю дайджест и думаю, что нужно почитать про остальные иероглифы. 

Иногда поражаешься, какие триггеры срабатывают и превращают зубрёжку неправильных глаголов в удовольствие! Когда-то именно чтение книги о французских колониях (государствах Магриба) дало мне наибольший толчок в изучении французского языка: почему-то загадочный мир Северной Африки в звучании парижской речи показался мне даже более привлекательным, чем традиционно манкие Лувр, Версаль, Канны, порт Бордо и Марсель. А ведь на тот момент мне казалось, что я ненавижу все эти глаголы, грависы и проч. 

А вообще, меня давно тревожит мысль: а знаю ли я язык достаточно хорошо? А насколько хорошо знают остальные? А почему один знакомый говорит как native speaker, а второй из его же группы — «иняз финишд»? Делитесь историями и достижениями, а я расскажу, что меня вдохновило в 37 лет сесть за учебники и начать качать французский с твёрдой целью дойти до устойчивого финиша.

Поднялся вопрос стандартизации коммитов в команде. До этого были такие правила, мы пишем номер задачи и через тире описание того, что было сделано кратко. Номер задачи берется из номера issue. Например: #1 - реализован функционал сборки прода. Но, это надоело и стало как-то неудобно, когда у нас есть четкое деление задач на фиксы, фичи и так далее.

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

В нашей команде принято по максимуму IDE и его возможности. То есть, коммиты мы делаем не через консоль, а через встроенные утилиты. Поэтому, сразу пошли искать плагины, которые есть в PHPStorm и нашли вот эти 2 важных плагина: Conventional Commit и Git Commit Template. После их установки видим новые кнопки в окне коммита:

Этот материал представляет собой глубокое исследование всего, что связано с Redis. В частности — речь пойдёт о различных способах организации хранилищ Redis, о постоянном хранении данных, о форках процессов.

Вступление

В стандарте SQL описывается четыре уровня изоляции транзакций — Read uncommited (Чтение незафиксированных данных), Read committed (Чтение зафиксированных данных), Repeatable read (Повторяемое чтение) и Serializable (Сериализуемость). В данной статье будет рассмотрен жизненный цикл четырёх параллельно выполняющихся транзакций с уровнями изоляции Read committed и Serializable.

Для уровня изоляции Read committed допустимы следующие особые условия чтения данных:

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

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

Что же касается Serializable, то данный уровень изоляции самый строгий, и не имеет феноменов чтения данных.

Эта статья стала итогом моих экспериментов в 2022-ом. С начала года я искала сервисы, которые помогают выкупать товары в интернет-магазинах за рубежом и доставляют их в РФ. 

Прочитав кучу отзывов (спойлер: в основном плохих), я попробовала заказать товары через так называемые “Сервисы-посредники” или “Байер-сервисы”. В статье расскажу об опыте работы с 8 сервисами, с помощью которых можно привести товары в Россию.