SQL *

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

В этой статье я покажу вам, как работать с Microsoft SQL Server в C# проектах посредством скриптинга. Реализовать это можно как в Windows, так и в macOS. Поскольку Windows, очевидно, является намного более популярной целевой платформой для C# и SQL Server, больше внимания я уделю настройке под macOS. В конце концов, код для этих платформ будет одним и тем же.

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

Кажется, что тут и споткнуться-то негде в реализации - но все оказывается совсем не тривиально.

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

Выковыривание информации из html — это скучно. Очень. Между тем, эта потребность выстреливает редко, но метко (© Суворов). Из-за этого есть спрос на готовые и короткие инструкции о том, как это сделать, чтобы не тратить время на изучение. Перед вами как раз такая.

Чтобы добавить хоть какой-то интерес скучнейшему занятию мы для примера будем парсить пользователей Хабра. А чтобы не мелочиться — ещё и реанимируем для этого экспериментальную библиотеку 11-летней давности.

Есть такой проект — htmlSQL. Старая библиотека времён Очаковских и покоренья Крыма (© Грибоедов). Она позволяет делать выборку из HTML в стиле SQL-запросов как на КДПВ, чем она мне когда-то и полюбилась.

Наступил Апокалипсис.

Нет, не стоит бежать запасаться банками с консервами и крышками отечественной бай-колы! Апокалипсис произошёл только в нашей фантазии и с определённой целью — чтобы проверить, а может ли человек, обладающий только книгами по теме и стандартной библиотекой языка, воссоздать инструмент, который будет служить ему верой и правдой?

Так родился учебный проект SicQL, реляционная СУБД, чей символ — сова — это олицетворение силы знаний и мудрости. Олицетворение тех знаний и той мудрости, которые мы получим, создав с нуля то, чем мы пользуемся каждый день, может, не осознавая всей сложности таких инструментов.

Приглашаю присоединиться к увлекательному путешествию!

Мотивированный ИТ-шник, он же реципиент почки, хочет что-то поменять в стране в плане трансплантации органов (лист ожидания).

То, что данные называют нефтью 21 века известно уже давно: на них учатся нейросети, их мгновенная обработка и передача сильно упростили нашу жизнь, и одной из самых распространенных структур хранения данных является реляционная. Именно с ней знакомы большинство разработчиков и, скорее всего, знания как с ней работать вам тоже понадобятся.

Основным инструментом для взаимодействия с реляционными БД является структурированный язык запросов или же SQL.

Привет! Меня зовут Пётр, я менеджер по отказоустойчивости в QIWI. В этом посте мы поговорим про выбор новых классов продуктов. Как-то раз мы с одним разработчиком из другой компании стали обсуждать, почему бы не выбрать для работы какую-то распределенную СУБД, поддерживающую SQL? Из этой дискуссии родился мой доклад для нашей QIWI Server Party. Представляю вам его текстовую версию.

Если вы не разобрались в тонкостях работы базы данных, то использование новых средств языка T-SQL может привести к неожиданным результатам в плане производительности.

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

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

История создания регулярных выражений берет свое начало с 1942 года. В то время Уолтер Питтс — американский логик, работавший, в основном, в области когнитивной психологии, работал  с известным физиологом Уорреном МакКаллоком. Основой их работы были труды связанные с теоретическим построением нейронных сетей. Немного позже, американский математик Стивен Клини изучал события в сетях МакКаллока-Питтса и предложил способ описания таких событий при помощи языка регулярных выражений.

Работа Клини вышла в середине 50-х годов двадцатого века. Научные труды были бы забыты, но американский программист Кен Томпсон в конце 60-х годов обнаружил, что регулярные выражения можно использовать для задания шаблонов поиска строк в длинных текстах. Смысл поиска заключается в том, что регулярное выражения преобразуется в конечный автомат, который производит поиск строк, которые должны соответствовать определенным шаблонам. Для построения конечного автомата Томпсон придумал специальный алгоритм, который сейчас носит название «построение Томпсона». Таким образом Кен Томпсон смог принести в мир стандарт для задания поисковых шаблонов.

Сами по себе, регулярные выражения есть ни что иное, как текстовый шаблон, который соответствует какому-то тексту. В трудах Джеффри Фридла пишется, что: «Регулярные выражения— это мощнейший инструмент, хорошо известный программистам. Однако он может быть полезен не только программистам, но и всем людям, работающим с кодом или простым текстом». При использовании регулярных выражений человеку придется работать с литералами и метасимволами. Это два существенно различающихся по своей сущности понятия. Литералы – это обычные символы, т.е. при записи в строках регулярного выражения они интерпретируются так, как они записаны. Примером литералов в регулярных выражениях может быть любая буквенная последовательность. В свою очередь, метасимволы интерпретируются при поиске особым образом. Примером может служить символ «*», который задает последовательность любого количества литералов.

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

Если не видели дайджест за прошлый год — время наверстать упущенное!

Они носят множество имен: Data Analyst, Data Scientist, Business Analyst и т. д., но всех их объединяет одна основная черта — эти люди занимаются анализом данных. Итак, начнем с главного. Сколько получают аналитики?

Участвую в стартапе, в котором разрабатывается СУБД нового типа (работает поверх некоторых kv-движков, кардинально расширяя их возможности, про это немного можно прочитать здесь). Для того, чтобы сравнить то, что понемногу получается, с тем, что имеется в индустрии, пришлось на глубоком уровне проработать первоисточники по темам Isolation и Consistency (уточню, что имеется ввиду не та Consistency, что в ACID). Обнаружил интересные нюансы, которые и излагаю в этой статье.

Тезисно:

• Термин Phantom Read является продуктом испорченного телефона
• Смысл понятий Lost Update, Write Skew и Read Skew для разделения уровней изоляций неочевиден и относителен
• Движок, который обеспечивает уровень изоляции Serializable, в распределённом мире может вести себя весьма причудливо, например, всегда возвращать пустой результат для read-only транзакций — и ему за это по стандарту "ничего не будет"
• Strong consistency в Cosmos DB — предел мечтаний? (спойлер: нет)

Ну, и ещё кое-что по мелочи. В конце рассмотрим вот такой венец творения человеческого разума:

 На сегодняшний день существует большое количество различных систем управления базами данных - СУБД, от коммерческих до открытых, от реляционных до новомодных NoSQL и аналогичных.

Одним из лидеров направления СУБД является PostgreSQL и ее различные ответвления, о некоторых из которых мы рассмотрим подробнее.

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

Итак, схемой мы будем называть логическое объединение таблиц в базе данных, а сама БД это физическое объединение таблиц. Индекс - отношение, которое содержит данные, полученные из таблицы или материализованного представления. Его внутренняя структура поддерживает быстрое извлечение и доступ к исходным данным.

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

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

Загрузить миллион записей в питон за секунду?
Нет. Получилось еще быстрее!

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

Продолжаем следить за новинками будущей 16-й версии. В начале декабря завершился третий коммитфест и вот его результаты.

Самое интересное из первых коммитфестов можно прочитать в предыдущих статьях серии: 2022-07, 2022-09.

Расскажу о такой важной особенности работы СУБД TERADATA, как сбор и использование статистик при выполнении запросов и как их наличие или отсутствие может повлиять на скорость выполнения таких запросов. Попытаюсь объяснить, что представляют собой статистики и для чего они нужны TERADATA.