MySQL *

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

Естественный путь профессионального становления, это когда ты сначала являешься кандидатом, и только проходишь интервью, ну или пытаешься, а потом, еще и проводишь интервью для других соискателей.

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

Привет, Хабр! 

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

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

И вот как раз о данных (а точнее о базах данных) в таких средах и хотелось бы поговорить. А именно — где и как их взять, как сделать их максимально приближенными к боевым и как защититься от их утечки. Для решения этих задач мы в Nixys используем собственный инструмент — nxs-data-anonymizer. Хотим поделиться им с вами.

Иногда (часто) во время разработки веб-сайта возникает необходимость реализовать поиск с фильтрацией, и отсортировать результаты по какому-то фиксированному полю: например, поиск товаров в интернет-магазине, поиск туров в турагентстве, показ логов с фильтрацией по содержимому, и т.д. Очень часто бывает так, что фильтрация должна осуществляться чуть ли не по любому полю (а полей десятки), а записей тысячи или даже миллионы. Если данных много, или же нужно их часто обновлять, то индекс на каждое поле не создать, ибо много места будут занимать, или же будут создавать слишком большую нагрузку на диск при записи, и приходится что-то придумывать. Давайте что-нибудь придумаем.

Сравнение, как работает операция GROUP BY в MySQL, PostgreSQL и MS SQL Server и что можно сделать, чтобы улучшить производительность запросов на столбцах с малым количеством уникальных значений.

K2 - в целом неплохой компонент (был). Некоторое время он давал гораздо больше возможностей для отображения контента, чем стандартный компонент материалов Joomla. Однако, время не стоит на месте, и сейчас стандартный компонент не уступает в возможностях компоненту K2. Разработчики Joomla потрудились на славу, чего не скажешь о разработчиках компонента K2. Мало того, что долгое время не обновлялся функционал компонента, так они не подготовили обновление для перехода на 4 версию Joomla. На момент написания этой статьи прошло почти два года с выпуска Joomla 4, а обновления компонента K2 для совместимости с новой версией так и нет. Возможно, на тот момент, когда вы будете читать эти строки разработчики K2 что-то выкатят, но сейчас нет.

При  умеренных объёмах базы данных в использовании offset нет ничего плохого, но со временем база данных растёт и запросы начинают «тормозить». Становится актуальным ускорение запросов.

Очевидно, если причина в росте объёмов базы данных, то используя главный принцип дзюдо «падающего - толкни, нападающего - тяни»,  следует ещё увеличить объём, в данном случае путём добавления нового поля в таблицы для последующей сортировки по нему.

По долгу службы, мы много работаем с деньгами. Складываем, вычитаем, считаем проценты. Любому школьнику известно, что для этих расчетов не подходят обычные встроенные в язык типы: флоаты не сойдутся у финансовых аудиторов, большие целые принесут кучу проблем при конвертации (например, йены обходятся без дробных единиц, а в одном оманском риале — 1000 баиз, а не сто, как у всяких плебейских долларов и евро), и так далее. Существуют целые комитеты, определяющие стандарты (ISO 4217 — коды валют и ISO 24165 — идентификаторы цифровых токенов). Во всех более-менее современных языках есть библиотеки для работы с денежными суммами, реализующие стандарты и скрывающие от нас адовую арифметику без потерь точности.

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

При проектировании таблиц в базах данных может возникнуть вопрос (я надеюсь) как хранить строки в char или varchar. Совсем недолго помучавшись почти всегда выбирается varchar, по причине того, что места занимает меньше. Собственно о последствиях этого выбора на реальном примере и поговорим , а так же о причинах по которым эти последствия возникают, и о неидеальных решениях этой проблемы.

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

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

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

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

Я очень люблю визуализации. Человек лучше всего воспринимает информацию через образы. Для трех часто встречающихся баз (MSSQL, Postgres и MySQL) я смастерил плагины к проекту Bell, хотя этот код на Python можно использовать и отдельно. Поэтому для каждой визуализации я буду в скобочках писать имя файла из репозитория GitHub - вы можете этот файл вытащить и использовать его отдельно от проекта (для этого нудны минимальные модификации).

Отмечу только, что я считаю себя экспертом только в MSSQL, а то что сделал с другими базами - сделал по наитию. Кроме того, в отличие от MSSQL у меня нет реальных баз под большой нагрузкой для Postgres и MySQL. Поэтому ошибки/пожелания для скриптов Postgres и MySQL очень и очень welcome!

В основном я задействовал TreeMap.

Привет, Хабр! Сегодня мы узнаем, как запустить надежный одноэлементный инстанс базы данных MySQL в качестве пода в Kubernetes и как предоставить этот под другим приложениям в кластере.

Мне 43 года и я профессиональный юрист. Неуемная интеллектуальная энергия и неудовлетворенность основной профессией 2,5 года назад привели меня в IT. Да-да, вот так – взрослая тетя с гуманитарным образованием решила попробовать себя на ниве программирования и замахнулась аж на такой язык как… JAVA!!!

Замахнулась, переквалифицировалась на дистанционных курсах одного крупного рогатого скота образовательного ресурса и, поскольку прагматичная жажда наживы необходимость зарабатывать на кусок хлеба с маслом здесь и сейчас не дает ей возможности оставить основное место работы и уйти на неведомые просторы для it-специалиста, решила совместить опыт юриста и знания java-разработчика.

Оглянувшись по сторонам и не встретив направленных на меня глаз я поняла – все эти глаза устремлены в гаджеты! Месседжеры и социальные сети правят умами. Значит, надо действовать через них.

И тут я вспомнила, что самый частый юридический вопрос, с которым ко мне обращаются друзья/знакомые – это просьба дать ту или иную форму документа (договора, расписки, заявления, доверенности и т.д.). Эврика! – нужна несложная мобильная программа с формами самых востребованных документов, чтобы их оставалось просто скачать и наполнить необходимыми сведениями. И тут самым коротким путем к конечному пользователю мне представился telegram-бот.

Поскольку на курсах таким тонкостям не учили, вооружившись статьями и видеороликами из всемирной паутины, закатав рукава я принялась создавать свою первую «взрослую» программу-помощника человечеству!

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

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

Следующий раздел предназначен для тех, кто не читал статью по бэкапам PostgreSQL, так как он повторяет основные моменты теории резервного копирования.

Привет! Предлагаем вашему вниманию перевод не новой, но способной оказаться полезной статьи. Автор делится полезными возможностями утилиты Mysqldump.