MySQL *

При проектировании таблиц в базах данных может возникнуть вопрос (я надеюсь) как хранить строки в 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.

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

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

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

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

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

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

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

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

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

Это вторая часть моих копаний во внутренностях MySQL. В первой части [habr] были затронуты запись страниц данных на диск (с промежуточной записью в DoubleWrite buffer) и запись бинлогов (с батчингом в виде group commit). В этой части я расскажу про redo log и как все части MySQL координируются для достижения надежной работы.

Почему для фольклорных экспедиций нужно писать программы?

Как быть со множеством фотографий, видео и аудио, которые необходимо каталогизировать, описать и поделиться с коллегами?

Рассказываю, как мы описываем примерно 200 часов интервью за 10 дней экспедиции.

В середине 2015 года, в MySQL 5.7.8 появился тип данных JSON. С тех пор он применяется, чтобы избегать жёстких определений столбцов и сохранять документы JSON всех форм и размеров: логи аудита, параметры конфигурации, сторонние полезные нагрузки, пользовательские поля и др. Подробности — к старту нашего курса по анализу данных.

Разработчики предъявляют высокие требования к базам данных: максимальная надежность (ничего из того, что было записано не должно быть утеряно ни при каких обстоятельствах), и, одновременно, максимальная производительность при различных видах нагрузки (Запись/Чтение или OLTP/OLAP). Достичь этих требований может быть не просто. Давайте попробуем разобраться, как это делает MySQL.

Размышляя о базе данных, легко представить таблицу базы данных как HashMap/BinaryTree, отображающие первичный ключ (primary key) в структурированные записи с данными. Такое хранилище может работать in memory. Но, как только мы захотим записать данные на диск, придется использовать какие-то алгоритмы во внешней памяти. Просто положить наш HashMap на диск не получится, потому что память и диски слишком разные: чтение/запись диска производится блоками, latency диска больше чем у RAM, а еще нельзя будет воспользоваться обычными указателями и аллокаторами памяти - все это придется заменить самостоятельно.

Entity Framework — это удобный фреймворк для работы .NET-приложения с базой данных. По сути, это такая удобная абстракция над БД, которая сама пишет за разработчика оптимальные (ну, почти) SQL-запросы прямо из высокоуровневых LINQ-конструкций. Одной из киллер-фич фреймворка является возможность относительно легко сменить СУБД приложения на какую-нибудь другую. Предположим, разочаровались вы в MySQL или, наоборот, хотите сменить MSSQL на что-то менее дорогое — пожалуйста, EF как абстракция над СУБД в теории может это предоставить, так сказать, by design.

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