Главная идея была в том, чтобы проверить возможно ли из старого Android устройства сделать "полноценный" сервер с nginx, php-fpm, MariaDB и запустить на этом Wordpress. Оказывается можно и при этом с хорошим результатом.
Устройство: Xiaomi Mi 4c 2015 года, разблокирован разгрузчик, TWRP, Android 10 (Havoc OS 3.0), Gapps не устанавливались для экономии ресурсов, root отсутствует.
Я новичок в работе с базами данных и для их изучения (а заодно для изучения Питона) начал небольшой пет-проект. В процессе оказалось, что в моей многопользовательской системе запросы к БД всегда касаются только одного пользователя. «Отлично!» подумал я, «раздам каждому пользователю по табличке и сэкономлю ресурсы сервера на индексации!». Конечно сначала я почитал литературу и подобных решений в ней не нашел. Потом сходил на один из популярных ресурсов и там мне объяснили, что так делать нельзя. Но почему – никто объяснить не смог (или возможно не захотел). Поэтому я решил сделать небольшой тест на самых популярных БД – проверить что будет на самом деле.
Почему программисты SQL так плохо шутят? Потому что их юмор — это всегда "SELECT * FROM jokes WHERE is_funny = 1".
MySQL научился использовать OpenSSL, чтобы шифровать трафик между клиентом и сервером году где-то в 1999. В принципе работало оно нормально, свою задачу выполняло, трафик шифровало. Но был там один фатальный недостаток. SSL в MySQL, а позже и в MariaDB, не работал сам, сразу. Его надо было настроить. И это было непросто.
Ну а что делать, сертификат-то проверять надо. Иначе это не защита, а пшик. Приходится терпеть. Так мы и терпели почти четверть века, и очень небольшое количество пользователей проходило квест настройки SSL до конца. Это должно измениться новом релизе MariaDB 11.3 (пока доступен только в виде превью тут).
Kysely.js – это библиотека, позволяющая писать типизированные SQL запросы. Библиотека делает работу с SQL в вашем проекте более безопасной, избавляя от таких ошибок как опечатки в названиях колонок или таблиц и неправильное использование SQL операторов в коде (код не скомпилируется). Ко всему прочему она делает работу с SQL более удобной, предоставляя при написании запросов автодополнения для таблиц, колонок, алиасов и других сущностей. Kysely имеет незначительный слой абстракции над SQL для того чтобы можно было пользоваться всей мощью SQL и при этом не изучать множество дополнительных сущностей. Библиотека поддерживает MySQL, PostgreSQL, SQLite, PlanetScale, D3, SurrealDB и другие.
Теперь погрузимся в наш кисель 😃.
Всем привет. Предлагаю сделать передышку и отойти от нашего хранилища бэкапов и рассмотрим еще возможности инструментов Nix. Мы поработаем с Postgresql,Mysql,Qemu и открытыми данными
В процессе работы над приложением, команда разработчиков часто сталкивается с необходимостью версионирования и трансляции изменений в структуре базы данных между различными машинами. Для этих целей сообществом были разработаны различные системы, отличающиеся функциональными возможностями, ценой (включая бесплатные решения) и технологиями организации процесса.
В этой статье я бы хотел подробнее остановиться на Nasgrate
Основные преимущества Nasgrate
• в качестве хранилища SQL-запросов используются обычные текстовые файлы без привязки к какому либо языку программирования. Это упрощает процесс взаимодействия между командами, работающими с разными технологиями (например Node и Python), не приходится разбираться в особенностях язковых конструкций
• возможность автоматического создания миграции на основе анализа изменений в двух базах данных (пока поддерживается только 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 нет ничего плохого, но со временем база данных растёт и запросы начинают «тормозить». Становится актуальным ускорение запросов.
Очевидно, если причина в росте объёмов базы данных, то используя главный принцип дзюдо «падающего - толкни, нападающего - тяни», следует ещё увеличить объём, в данном случае путём добавления нового поля в таблицы для последующей сортировки по нему.
