MySQL *

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

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

Пару слов о необходимом арсенале.

Для решения задачи, понадобится следующее:

Эта инструкция - для тех, кто, как и я, желает всегда иметь под рукой развернутый "гайд" с нелинейным сюжетом по MySQL. В статье рассмотрены 3 способа организации переменных окружения для повышения удобства запуска сервера и клиента СУБД: 1) с помощью Панели управления, 2) редактированием реестра и 3) консольными командами Windows. Также представлено скромное размышление на тему рациональности использования того или иного подхода.

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

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

Помните! Только истинный живой интерес и отсутствие страха перед смертью вытащили человечество из пещер в каменные дома (по сути, те же пещеры, только с доступом в Интернет...).

PostgreSQL и MySQL являются самыми популярными Open Source реляционными базами данных. И часто возникает вопрос - чем отличается PostgreSQL от MySQL? Ответ на этот вопрос позволит понять, какая из баз данных лучше подойдет вашему проекту.

В данной статье мы сравним PostgreSQL и MySQL по различным параметрам и запишем их в сравнительную таблицу.

Как следует из названия, данная статья для тех, у кого есть сложности с пониманием SQL запросов, в составе которых, используется EXISTS, т.к., исходя из опыта, его использование частенько вызывает вопросы у начинающих, а иногда даже у продолжающих. 

Стандартное описание работы оператора EXISTS, для SQL, выглядит примерно так: “Оператор EXISTS возвращает true, если подзапрос возвращает одну, или более записей, в противном случае, возвращает false”. 

И еще: “Поскольку возвращения набора строк не происходит, то подзапросы с подобным оператором выполняются довольно быстро.”

Непонимание, обычно, как раз кроется, где-то здесь: Если EXISTS возвращает true/false, но не возвращает набор записей, то каким образом, основной запрос, в ходе выполнения, отбирает записи, соответствующие условиям описанным во вложенном запросе.

Самостоятельное изучение программирования, в частности принципов работы с базами данных, к сожалению, предвосхищает многочасовое погружение в многостраничные руководства, которые, как правило, еще и написаны на английском языке. И проблема заключается вовсе не в уровне языковой подготовки. Все, что познается впервые, кажется каким-то непонятным, мудреным, особенно дезориентирует обилие перекрестных ссылок, когда документы, к которым они ведут, еще и ссылаются друг на друга. Руководство по MySQL кишит обилием подобных паутин. В общем, как-то давно я устанавливал и переустанавливал noinstall-версию этой СУБД для личных нужд, но сегодня просто забыл порядок действий. Поиски внятных инструкций на русском в интернете выдали единственную адекватную статью по установке MySQL noinstall archive на Windows за 2016 год на, как мне показалось, одном из заброшенных блогов рунета. Эта ситуация замотивировала меня еще раз досконально пройти весь путь от загрузки дистрибутива, до запуска сервера и более детально изучить соответствующие позиции "мануала". Я пишу эту инструкцию для тех, кто, как и я, желает освоить ручную установку MySQL и немного глубже погрузиться в проблематику данной предметной области, а также всегда иметь перед глазами полноценное, 100%-е, руководство. Я надеюсь, что создание подобных отправных точек снизит порог вхождения для новичков, не имеющих возможности обратиться к кому-то за помощью, и увеличит количество желающих глубже разбираться в функционировании СУБД на примере MySQL.

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

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

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

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

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

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

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