SQL *

Цели, которых я хотел достичь

• Excel, как результат селекта, текст которого процедура узнает только в runtime
• Селект перед выпонением видоизменяется в соответствии с параметрами, которые получает процедура
• Процедуре передаются параметры файла, который будет создан
• Возможность получения результирующего файла в форматах Excel Workbook,CSV,HTML,XML

Хранимая PL/SQL процедура получает в параметрах

• текст селекта
• параметры файла Excel
• параметры выполнения

и создает полноценный Excel с несколькими таблицами(sheets).
Я знаю, что есть Crystal Reports и Oracle BI Publisher.
Но, во-первых, это крупные продукты(с большими ценами...), а Publisher, насколько я знаю не работает как отдельный модуль без Oracle Business Intelligence Enterprise Edition. И кроме того, речь шла о довольно узкой задаче создания файла без layout.

В конце, я написал один PL/SQL пакет, который находится в database и может быть вызван из любой аппликации. В ходе написания я столкнулся со многими ограничениями и хочу рассказать о том, как их поборол.

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

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

Несколько слов об исходной задаче. Основная сущность у нас — профиль ICQ, у которого есть список контактов, а у тех есть сообщения. Наше приложение существует уже много лет, разрабатывалось разными людьми с разными подходами, номер версии основной БД уверенно приближался к 30. Кроме того, количество фич в продукте невозможно предсказать заранее, это тоже повлияло на архитектуру. В общем, модель данных изначально была примерно такой:

Я бы хотел обсудить принцип разделения ответственности (Separation of Concerns, SoC) в контексте ORM, а также посмотреть почему этот принцип так важен. Также мы рассмотрим примеры нарушения границ ответственности между доменной логикой и логикой сохранения данных.

При разработке отчетов (программ) SAP на языке ABAP для обращения к базе данных используются Open SQL-запросы. Синтаксис очень похож на SQL, но имеются некоторые отличия. Одно из таких отличий – возможность использования конструкции FOR ALL ENTRIES IN. Эта конструкция применяется в SELECT запросах до оператора WHERE. После неё указывается внутренняя таблица с данными, поля которой можно использовать в операторе WHERE в качестве условий выборки.

В этой статье я хочу рассказать о тонкостях работы этой конструкции: что происходит на уровне БД, об оптимизации запросов и о database-hints.

^{Капитан Немо у штурвала «Наутилуса»}

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

Здесь я расскажу о том, как устроены индексы и как они работают. Однако я не ожидал, что в их основе лежит информатика. В понимании подноготной индексов также помогли комментарии в коде, объясняющие не только как работает Postgres, но и почему он так работает.

В сети уже есть довольно немало сравнений Entity Framework и NHibernate, но все они по большей части фокусируются на технической стороне вопроса. В этой статье я бы хотел сравнить эти две технологии с точки зрения Domain Driven Design (DDD). Мы рассмотрим несколько примеров кода и увидим как эти две ORM позволяют нам справляться со сложностями.

При проектировании информационной системы выявляются некоторые слои, которые отвечают за взаимодействие различных модулей системы. Соединение с базой данных является одной из важнейшей составляющей приложения. Всегда выделяется часть кода, модуль, отвечающающий за передачу запросов в БД и обработку полученных от неё ответов. В общем случае, определение Data Access Object описывает его как прослойку между БД и системой. DAO абстрагирует сущности системы и делает их отображение на БД, определяет общие методы использования соединения, его получение, закрытие и (или) возвращение в Connection Pool.

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

Тема полиморфных связей уже поднималась не раз на Хабре («Rails и полиморфные связи», «Полиморфные сквозные ассоциации в Ruby on Rails», «Полиморфные связи»), но поднималась она в контексте Ruby, и для тех, кто уже имеет какой-то опыт в проектировании БД. Новичкам же (мне было), мало что понятно из тех статей, поэтому в данной статье я попытаюсь рассказать всё на пальцах, абстрагируясь от языка, разве что немного задену ORM популярных фреймворков в вебе.

Чаще всего deadlock описывают примерно следующим образом:
Процесс 1 блокирует ресурс А.
Процесс 2 блокирует ресурс Б.
Процесс 1 пытается получить доступ к ресурсу Б.
Процесс 2 пытается получить доступ к ресурсу А.
В итоге один из процессов должен быть прерван, чтобы другой мог продолжить выполнение.
Но это простейший вариант взаимной блокировки, в реальности приходится сталкиваться с более сложными случаями. В этой статье мы расскажем с какими взаимными блокировками в MS SQL нам приходилось встречаться и как мы с ними боремся.

В предыдущей части были рассмотрены основы уровней изоляции транзакций. Здесь я постараюсь копнуть чуть глубже и рассказать при помощи каких инструментов MS SQL Server реализует уровни изоляции.

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

• Основанный на блокировке ресурсов
• Основанный на создании версионной копии ресурсов.

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

Мне часто приходилось сталкиваться с тем, что люди прекрасно понимают, что такое транзакции в базе данных и для чего они нужны, но при этом не всегда умеют ими правильно пользоваться. Безусловно, для достижения 80-го уровня сакрального знания нужно иметь не один год опыта и прочесть множество толстенных книг по SQL. Поэтому в этой статье я даже не буду пытаться описать всё, что может быть связано с транзакциями в MS SQL. Я хочу затронуть один простой, но очень важный вопрос, который разработчики часто упускают из вида – уровни изоляции транзакций.
Несмотря на то, что тема очень проста, во многих источниках она освящается плохо – информации либо очень мало, либо очень много. Т.е. прочитав 5-6 кратких теоретических определений невозможно их применить на практике. Для уверенного понимания предмета статьи нужно обращаться к специализированной литературе, но там информации на столько много, что далеко не каждый может уделить необходимое время для её усваивания.
Сегодня я хочу поделиться своим простым рецептом, который помог мне раз и на всегда запомнить особенности уровней изоляции транзакций и по сей день помогает без проблем принимать взвешенные решения о выборе необходимого уровня.

Хочу поделиться с хабрсообществом проектом из области business intelligence, которым я занимаюсь в свободное время последние полтора года.

Многие используют табличные процессоры (Excel, OpenOffice Calc и т.д.) для быстрого создания приложений, которые выполняют простые вычисления, помогают при создании отчётов или облегчают планирование. Несмотря на то, что возможности таких приложений, как правило, очень ограничены, простота табличных процессоров делает такой подход очень популярным. Речь в этой статье пойдёт о попытке расширить возможности табличных процессоров с помощью многомерной модели данных (обычно ассоциируемой с понятием OLAP), стараясь при этом не слишком усложнить работу с новым инструментом. Кому интересно читаем дальше.

Пока готовится подробный обзор функционала MS Datazen и Pyramid Analytics, мы решили разместить небольшую статью по решению локальной задачи для SQL Server Reporting Services.

Недавно, при создании отчетов в SSRS столкнулись с такой задачей:
необходимо создать два связанных отчёт так, чтобы можно было перейти из основного отчета во вспомогательный, а из вспомогательного вернуться в основной с передачей параметров.
Ограничения:
основной отчёт изначально загружается со значениями параметров по умолчанию, а все возможные значения ограничены набором из запроса.

Данная статья подготовлена Алексеем Струченко, начальником отдела оптимизации СУБД и приложений компании «Инфосистемы Джет»

Вышедшая в июле 2014 года опция Database In-Memory является самой ожидаемой и самой обсуждаемой инновацией Oracle в семействе продуктов Oracle Database. За последние несколько месяцев сотрудники компании Oracle регулярно знакомили российское оракловое сообщество с особенностями новой опции.

На Oracle Day 2014 в Москве мне выпала честь дополнить теоретическую презентацию Игоря Мельникова (Oracle) по Database In-Memory практической демонстрацией. Эту демонстрацию в полном объеме показать не удалось – оказалось не так-то просто подключить проектор к ноутбуку, соединенному с демонстрационной базой. Поэтому я решил воспользоваться трибуной Habrahabr и все-таки донести суть демонстрации Database In-Memory до сообщества.

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

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

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

Перейдем к делу.

Всем привет! В нашем предыдущем посте про облачный сервис Cackle мы рассказали об архитектуре, технологиях и нагрузках в целом. Сегодня хотим поделиться о том, как в условиях столь сильных нагрузок и уже накопленной информации (30 000 000 комментариев с 2011 года) мы сделали подробную аналитику для системы комментариев Cackle. Наш метод сбора статистики универсальный и думаю будет интересен, в плане практического применения, всем тем, кто столкнулся с задачей разработки аналитики, но пока не совсем представляет с чего начать.

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

Свой рассказ я хочу начать с такой вот веселой картинки:



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

«24 Hours of PASS» — это ежегодная онлайн-конференция о MS SQL Server, проводимая по эгидой профессиональной ассоциации PASS, и длящаяся 24 часа. Вот прям буквально 24 часа: докладчики из разных частей света сменяют друг-друга в марафоне вебинаров (конечно же, это отсылка к 24 часам Ле-Мана).

Усилиями Андрея Коршиков, уже несколько лет проводится русскоязычная версия «24 часа PASS». Последняя состоялась в середине марта, и если вы ещё не успели посмотреть все 24 часа видео (кстати, вот плей-лист на YouTube), то именно для вас я и сделал этот обзор.

• SQL Server 2014 In-Memory OLTP — Сергей Олонцев
• Размер имеет значение: 10 способов уменьшить размер БД — Дмитрий Короткевич
• Внутри оптимизатора запросов: Соединения — Дмитрий Пилюгин
• Оптимизация SSAS-кубов — Евгений Полоничко
• Тяп-ляп и в продакшн! — Алексей Ковалёв
• Оффлайн-разработка баз данных и тестирование с SSDT — Андрей Завадский
• Deadlocks 3.0. Final Edition — Денис Резник
• BIML — лучший друг для SSIS-разработчика — Андрей Коршиков
• Power BI Q&A — Константин Хомяков
• Azure Data Factory — облачный ETL — Сергей Лунякин
• Все что вы хотели узнать о Workspace memory — Мария Закурдаева
• Быстрый анализ производительности SQL Server за 1,5 часа — Кирилл Панов
• Внутреннее устройство страниц и экстентов SQL Server — Алексей Князев

Недавно на Хабре появилась обзорная статья об инструментах Microsoft MAPT. Программа предназначена для проведения инвентаризации ИТ-инфраструктуры, помощи в миграции машин на новую версию ОС, оценки загруженности серверов, консолидации их на платформе Hyper-V и т.п. Мы решили рассказать о реальном опыте использования этого инструмента для решения настоящих бизнес-задач.

Задача, которая стояла перед нашей компанией, состояла в проведении точной и аккуратной инвентаризации всего ПО на рабочих станциях пользователей с последующей его рационализацией. Последняя основывается на создании так называемого MAL, или списка стандартного ПО, которое будет разрешено для использования в компании. Основная идея – управлять ПО, а именно — сократить количество ПО, проведя стандартизацию по версиям, редакциям и языкам там, где это возможно, а также учесть функционал приложений и некоторые вопросы лицензирования. Сокращая количество разрешённого ПО, мы не только экономим на лицензиях, но и уменьшаем стоимость поддержки пользовательских приложений.

Если вы интересуетесь ИТ, то вам, скорее всего, не нужно объяснять, что такое MySQL. А если вы знаете про MySQL, то наверняка вам знакомо имя Майкла Монти Видениуса. Для всех остальных и тех, кто подзабыл, напоминаем: MySQL – самая популярная в мире система управления базами данных, а Монти – её создатель, основатель компании MySQL AB, знаменитый ИТ-гуру и просто горячий финский парень.



25 мая, то есть в ближайший понедельник, Монти будет в Москве и проведёт мастер-класс, на котором поделится секретами вывода софтверных проектов на рынок, расскажет о том, как построить карьеру в ИТ, как продать компанию за миллиард долларов и начать всё сначала, приоткроет свои планы на будущее.