SQL *

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

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

Давайте сделаем это.

Данная статья является переводом, оригинальная статья находится вот здесь, автор Rob Conery.

Postgres, как многие знают, поддерживает JSON как тип хранения данных, а с выходом 9.4, Postgres теперь поддерживает хранение JSON в виде jsonb — бинарного формата.

Это прекрасные новости для тех, кто хочет шагнуть дальше простого «хранения JSON как текста». jsonb теперь поддерживает индексирование с использованием GIN индекса, а также имеет специальный оператор запросов, который позволяет получить преимущества GIN индекса.

После того как при помощи TSQL была успешна решена «Балда» (статья) я решил попробовать решить на нем «Судоку» (спасибо за идею shavluk).

Решение судоку получилось на удивление достаточно простым.

Базовая схема имеет следующий вид:

Ко мне как к студенту первокурснику Университета Иннополис часто обращаются с вопросом, чем же мы тут занимаемся. Специально для хабра я написал сказ о том, как мы проект по DMD «пилили».



Внимание! Автор не гарантирует, что его шутки будут понятны и смешны.

Еще недавно в моей памяти отложился анонс SQL Server 2016, которую лично презентовал Сатья Наделла. И вдруг, как снег на голову, стали одна за одной выходить свежие Community Technology Preview (на данный момент самая свежая версия – CTP3.1). По мере знакомства с новой версией, все больше хотелось поделиться впечатлениями…

Далее обзор новых синтаксических фишек SQL Server 2016: JSON, GZIP, DROP IF EXISTS, TRUNCATE TABLE по секциям, новые функции…

#1 – DROP IF EXISTS

CREATE TABLE dbo.tbl (
    a INT, b INT,
    CONSTRAINT ck CHECK (a > 1),
    INDEX ix CLUSTERED (a)
)

Если раньше перед удалением объекта приходилось делать проверку:

IF OBJECT_ID(N'dbo.tbl', 'U') IS NOT NULL
    DROP TABLE dbo.tbl

То сейчас появился более компактный синтаксис:

DROP TABLE IF EXISTS dbo.tbl

Хотелось рассказать о том, как многими любимый Sublime Text можно использовать как неплохое средство для разработки на PL/SQL.

Хотелось бы начать с того, для чего нужен был этот велосипед, ведь есть вроде бы много других IDE для работы с SQL и в частности Oracle PL/SQL, такие как Toad for Oracle, SQL Navigator, PL/SQL Developer и даже бесплатный Oracle SQL Developer, однако у большинства из них есть несколько недостатков по сравнению с текстовыми редакторами типа Emacs, SciTe, Vim, Notepad++, Sublime Text и т.д.

Перечислю некоторые из них, данный список сугубо субъективный:

• “Тяжеловесность” каждой IDE, это выражается не только в размере дистрибутива, но и общими ощущениями, наличием множества не нужных функций, кнопок, отзывчивостью и т.д.
• Большинство приемлемых IDE являются платными, или условно бесплатными с ограниченным функционалом.
• Хотелось бы кроссплатформенность, под это требование из приведенных IDE попадает только Oracle SQL Developer.
• Функционал редактирования текста. В большинстве из них есть только базовые методы по работе с текстом: это набор текста, copy-paste, подсветка синтаксиса. Ни о каких “CTRL+D” как Sublime Text речи и не идет.
• Простота расширения, практически все IDE закрыты, никакой поддержки самописных пагинов и т.д.

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

Если идти всё прямо да прямо, далеко не уйдешь…
(Маленький принц, Антуан де Сент-Экзюпери)

Недавно ко мне обратился коллега с просьбой как-то помочь с Teradata. Eё сейчас активно внедряют и первым шагом этого внедрения является загрузка данных на ежедневной основе. Заливать приходится очень много и как можно быстрее. Меня попросили найти какие-нибудь альтернативные способы загрузки данных в Teradata, которые бы не сильно зависели от выделенных пользователю ресурсов. В процессе этой работы мне пришлось более близко познакомиться с .NET Data Provider for Teradata. Входе знакомства выяснились некоторые любопытные детали, знание которых, на мой взгляд, может быть очень полезным. Так как о Teradata знают не все, начну я с краткого её описания.

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

Давайте начнем с простого… Эти запросы отличаются чем-то друг от друга с точки зрения конечного результата?

SELECT COUNT(*) FROM Sales.SalesOrderDetail
SELECT COUNT_BIG(*) FROM Sales.SalesOrderDetail

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

На днях я задался вопросом – насколько сложно будет реализовать алгоритм этой игры для компьютерного соперника?

Так как мне больше всего нравится работать с реляционными данными и моим любимым языком является SQL, то я решил совместить приятное с полезным и попробовать написать этот алгоритм используя только TSQL. Это моя первая попытка написать ИИ используя только возможности SQL.

Архив с файлами можно скачать по следующей ссылке – скрипты.
Все слова в словаре в верхнем регистре, а также в нем буквы «Е» и «Ё» считаются за одну (как «Е»).

В результате была создана следующая схема:

Exasol — это современная высокопроизводительная проприетарная СУБД для аналитики. Ее прямые конкуренты: HP Vertica, Teradata, Redshift, BigQuery. Они широко освещены в Рунете и на Хабре, в то время как про Exasol на русском языке нет почти ни слова. Нам бы хотелось исправить эту ситуацию и поделиться опытом практического использования СУБД в компании Badoo.

Exasol базируется на трех основных концепциях:

1. Массивно-параллельная архитектура (англ. massive parallel processing, MPP)

SQL-запросы выполняются параллельно на всех нодах, максимально используя все доступные ресурсы: ядра процессоров, память, диски, сеть. Понятие «мастер ноды» отсутствует — все серверы в системе равнозначны.

Отдельные стадии выполнения одного запроса также могут идти параллельно. При этом частично рассчитанные результаты передаются в следующую стадию, не дожидаясь окончания предыдущей.

2. Колоночное хранение (англ. columnar store)

Exasol хранит данные в колоночной форме, а не в форме отдельных рядов, как в классических СУБД. Каждая колонка хранится отдельно, разделяется на большие блоки, сортирируется, сжимается и равномерно распределяется по всем нодам.

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

Мы в Хекслете учим людей программировать, но стараемся хитрить: например, под видом простого, на первый взгляд, курса по PHP, рассказываем людям про абстракции, рекурсии, функции первого класса, замыкании, свертку и вообще начинаем «Основы программирования» с МИТ'шного СИКПа, а не с классов и формочек. В этом и других курсах, а также в наших регулярных вебинарах рассказываем о функциональном программировании, о проблемах современных подходов и о главном зле: состоянии. В нашем чате постоянно поднимаются крупные дискуссии, в которых выясняется, что изменяемое состояние в разы повышает сложность в системе.

Сегодня мы публикуем перевод статьи, в которой Пиотр Солница, один из создателей популярного DataMapper для Ruby, рассуждает в подобном ключе о взаимодействии с базой данных.

* * *

Я продвигаю функциональный подход в Ruby уже давно, и, хотя он включает в себя много различных методов и моделей, есть одна идея, одна фундаментальная идея, которая меняет всё: неизменяемость (иммутабельность).

Но что это вообще означает в Ruby? Запретить изменять любые объекты? Будет слишком медленно, так что — нет. Иммутабельно-ориентированный дизайн означает, что вы избегаете те интерфейсы, которые могут изменять объекты. Да, много методов в Руби изменяют состояние, но когда вы разрабатываете интерфейсы объектов, вы можете создавать их таким способом, что объекты не будут изменяться.

Использование неизменяемых объектов стало для меня шокирующим открытием. Одна из вещей, которую я понял после того открытия, это почему object-relational mapping (ORM) — плохая идея, и из-за нее у нас так много ненужной сложности.

Была задача — в ходе подготовки демки одного из решений надо было показать, что клиентскую информацию можно сохранять где угодно — в простом случае, например, в таблицах Google, в более сложном (после полугодового «внедрения»и многомиллионного бюджета) в CRM клиента. В используемой нами WSO2 ESB есть коннектор к таблицам Google — но реализовать требуемый функционал на нем оказалось не очень простой задачей — и тогда я на это забил.

Но вот недавно, разбираясь с новыми фичами WSO2 Data Services Server обнаружил, что в нем можно легко реализовать SOAP-сервис для работы с таблицами Google (который потом можно подцепить где угодно). Причем работа с данными в таблице осуществляется через привычный всем SQL.
О том, как это сделать, и хочу рассказать под катом.

В прошлой статье «Игра со списками условий» я показал, как строить запросы. В качестве примера я взял несколько условий, написанных на SQL, и использовал их в запросе.

Но пользователь не умеет писать на SQL, пользователя нельзя подпускать к написанию запросов. Но как же быть, если очень надо? Я предлагаю дать пользователю простой инструмент, результаты которого уже трансформировать в SQL.

Накидаем список вопросов:

1. Что нужно пользователю?
2. Какими понятиями может оперировать пользователь?
3. Как нам преобразовать эти понятия в запрос?
4. Как нам проверить, что условие составленное пользователем охватывает все множество записей?
5. Как нам сделать не одноразовый инструмент?

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

Возможность резервирования места на диске без инициализации называется Instant File Initialization (мгновенная инициализация файлов).

Фича эта не сильно известна, хотя ее использование стало возможным начиная с SQL Server 2005.

Какие преимущества можно получить от Instant File Initialization:

1. Ускорить создание новой базы данных
2. Сократить задержки и уменьшить время необходимое для увеличения файлов данных
3. Сократить время старта SQL Server, поскольку инициализация tempdb будет более быстрой
4. Сократить время при восстановлении из резервной копии, поскольку перед восстановлением SQL Server резервирует место под файлы, а потом переносит в них информацию из бекапа.

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

Введение

На самом деле я рассматриваю эту cms только как пример, того что присутствует во многих и опенсурс, и коммерческих системах. Просто мне как фрилансеру до недавних пор приходилось работать почти всегда с разработкой сайтов по дешевле и побыстрее – может у других фрилансеров много «жирных» клиентов, я не знаю, у меня не было. Так вот такая ситуация привела к не плохому опыту работы на модыксе. Но открытие собственной компании и дальнейшее подтягивание клиентов с индивидуальными запросами, потребовало вспоминать и улучшать свой лвл в настоящем программировании и построении баз данных. И вот тут я и почувствовал какой-то дискомфорт, что ли, ну как минимум смущение при воспоминании структуры как MODx, так и некоторых других открытых систем. Далее поясняю подробнее, что именно показалось странным, но интересным.



Дело в том, что в MODx Revo основным понятием для построения структуры сайта являются ресурсы. Вот именно, там нет такого как, например, в том же Вордпрессе отдельно страницы сайта, отдельно записи блога. Все страницы и записи, и даже много чего еще реализуется через модель ресурсов сайта. На самом деле это удобно, особенно учитывая тот факт, что это cmf/cms, то есть система рассчитана на разработку совершенно разных сайтов и тематически и технически. Таким образом, за всей структурой сайта удобно следить в одной панели управления ресурсами. В общем, система ресурсов позволяет создавать и управлять следующими сущностями сайта (хотел было написать объектами, но в ООП это слово уже занято, так что пусть будет «сущности»):

• Обычные html-страницы;
• Разного рода категории и разделы блога или каталога;
• Товары и их категории;
• XML-документы, например, sitemap.xml для поисковых роботов;
• Текстовые документы, к примеру, robots.txt правильно сделать ресурсом, а не просто залить файлом;
• Json-страницы, которые лично я использую для того же аякс;
• Создать собственный формат текстового файла.

Постановка проблемы

Вот такое объединение множества различных «сущностей» сайта в объекте одной модели Resources и вызвало мой интерес. Разум философа зашевелился и начал выдавать множество предположений и вопросов.

Во-первых, я обратил внимание на пользователей, потому что они сделаны совершенно отдельно от ресурсов. Как бы на первый взгляд это логично, но с другой стороны, если начали такую пляску с объединением кучи всего, почему бы не сделать все до конца. Да-да, максимализм в деле. Тем более, что сделать пользователей как один из видов ресурсов не представляет большой проблемы. В случае с modx это по большей части реализуется с помощью плейсхолдеров, позволяющих расширить количество атрибутов ресурса, и «контекстов», дающих возможность выделять часть ресурсов по их назначению. Реализация же чего-то подобного на фреймворке (я имею ввиду php-фреймворки) или голой связке скриптов и реляционной базы данных совсем дело не сложное.

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

В этой статье я хочу рассказать, как можно решать задачу impact анализа или анализа влияния в сложной, многоуровневой инфраструктуре корпоративного хранилища данных на примере нашего DWH в Тинькофф Банке.



Работая с DWH все наверняка задавались хоть раз вопросами:

• «Что будет, если поменять поле в таблице?»
• «На каких ETL процессах это скажется?»
• «Какие отчеты будут затронуты?»
• «Какие бизнес процессы могут пострадать?»

Ответить на этот вопрос как правило непросто, т.к. нужно просмотреть дюжину ETL процессов, потом залезть в BI инструмент, найти нужные отчеты, что-то держать в голове, помнить о том, что что-то там строится ручным кодом и всё это выливается в большую головную боль.
Даже самое порой безобидное изменение может сказаться, например, на отчете, который каждое утро приходит на почту к председателю правления банка. Немного утрирую, конечно:)

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

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

Для примера возьмём Stack Overflow. Он использует клёвую систему репутации с наградами за определенные достижения. Как и во многих социальных проектах, они поощряют пользователей ежедневно посещать ресурс. Обратим внимание на эти две награды:



Нетрудно понять, что они означают. Зайдите на сайт в первый день. Затем на второй день. Затем на третий (возможно несколько раз, это не имеет значения). Не зашли на четвёртый? Начинаем считать заново.

Официальная версия Firebird 3.0 Release Candidate 1 для Windows и Linux (а также исходники) доступна для скачивания на www.firebirdsql.org.

Список новых функций и возможностей можно найти в Firebird Release Notes (идут в составе архива установщиков Firebird).

Для российских пользователей Firebird "Московская Биржа" и наша компания (IBase/IBSurgeon) приготовили специальный, очень приятный бонус — бета-версию документации по языку Firebird 3.0 (PDF).
Полная версия документации ожидается вместе с релизом Firebird 3.0.
И еще — будет второй релиз-кандидат, ориентировочно через месяц.

В этой статье я покажу, что и как можно сделать со списком условий. Я сформулирую небольшую тестовую задачу на основе базы AdventureWorks2008R2 и один из вариантов ее решения.

Пример задачи:

Рассчитать стоимость доставки по факту по следующим условиям (обычная задача для логистических компаний).

Список условий:

• Доставка в Берлин и Бонн байков
• Доставка в Берлин и Бонн других товаров
• Доставка в другие города