SQL *

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

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

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

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

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

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

– у меня полетели диски/кто-то удалил мою базу… как мне восстановить мои данные?
– у вас есть свежий бекап?
– нет

Чтобы не стать героем такой ситуации, нужно потратить минимум усилий. Во-первых, выделить дисковый массив, на который складывать резервные копии. Поскольку, хранить бекапы вместе с файлами БД – явно не наш выбор. Второе… это создать план обслуживания по резервному копированию баз данных.

Что мы и сделаем далее, а после обсудим некоторые тонкости связанные с бекапами.

Несколько дней назад исходные коды первого релиз-кандидата версии Firebird 3.0 были зафиксированы в репозитории Firebird Project. Обычно проходит несколько недель с момента фиксации исходного кода до выпуска официального инсталлятора, поэтому мы в IBase.ru выпускаем неофициальный инсталлятор,

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

declare @sql varchar(100) = 'select 1+1'
execute( @sql)

1. Запуск строки через Execute создает отдельный блок кода, в котором текущие переменные будут не видны, но видны все временные таблицы.

2. Обратите внимание на передачу переменных со значением NULL. Любое слияние с NULL в результате даст NULL, следовательно, вместо запроса, вы можете получить пустую строку.

declare @i int
declare @sql varchar(100) = 'select ' + cstr(@i)
execute( @sql ) -- Ошибка

3. Передачу дат и времени. Даты лучше передавать в формате ГГГГММДД. При передаче параметров со временем следует обратить внимание на потерю точности. Для сохранения точности значения лучше передавать через временную таблицу.

Как известно, между объектно-ориентированной и реляционной моделью существует концептуальный разрыв, преодолеть который не в состоянии даже ORM. В основном этот разрыв влияет на то, что при использовании реляционной базы данных мы вынуждены работать над множествами, а не над конкретными объектами. Но есть и другой фактор: поведение NULL в бд отличается от поведения NULL в объектно-ориентированных языках. Это может стать проблемой, когда вы используете один и тот же запрос в двух ситуациях: 1) при запросе к бд 2) при юнит-тестировании, когда вместо таблицы из бд используется массив в оперативной памяти. Более того, это может стать проблемой, если вы обращаетесь только к бд, но мыслите о NULL в терминах ООП, а не реляционной бд!

Представьте: есть селект, который возвращает записи, каждую из которых нужно обработать, и то ли много записей, то ли обработка каждой записи занимает много времени, а процесс обработки одной записи не зависит от процессов других записей.
Классический пример для того, чтобы задействовать многопоточность или в случае баз данных выполнять обработку в нескольких сессиях. В Оракле для этого используется hint /*+ parallel() */ и pipelined functions. Это здорово, но если у вас Oracle standard edition(где parallel не работает) или вы хотите обработать не каждую запись по отдельности(из соображений, что лучше накопить работу, а потом в bulk, одним ударом, выполнить), а поделить весь вывод селекта на куски и каждый обработать отдельно?

JetBrains приближается к релизу новой IDE для работы с SQL и базами данных. Мы запустили EAP программу год назад и благодарим всех её участников. Как всегда, ваши мнения и пожелания сделали наш продукт лучше.

Мы рады представить вам 0xDBE 1.0 Preview. Это отличный шанс попробовать нашу новую IDE и поделиться впечатлениями, что поможет нам сделать 0xDBE ещё лучше к моменту релиза.



Нам нравится название 0xDBE, но оно всё же рабочее, и к релизу мы выберем другое — более читаемое.

Ещё мы хотим лучше узнать наших пользователей и понять, как вы работаете с базами данных, поэтому составили небольшой опрос. Просим пройти его, на это уйдёт 5-8 минут. Среди тех, кто принял в нём участие, мы разыграем десять годовых лицензий на 0xDBE.

Итак, вот что мы добавили с момента запуска EAP:

Быстрая и точная интроспекция

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



Управление объектами БД

При нажатии Ctrl+F6 (Cmd-F6 для OS X) на имени таблицы в текстовом редакторе или в окне Database view открывается окно Modify Table, в котором можно добавлять и удалять столбцы, менять их свойства, добавлять и удалять ключи и индексы. В реальном времени генерируется DDL-скрипт, который будет выполнен для этих изменений:



Текстовый поиск

Теперь доступен текстовый поиск по результату запроса. Например, вам нужно найти данные, а столбец забыли. Есть поддержка регулярных выражений:

Хочу на простом примере рассказать о том, как иногда можно сильно оптимизировать вполне простые на первый взгляд запросы. Возьмем такой код, для примера на PostgreSQL 9.3, но принцип подходит ко всем субд, в которых присутствует hash join.

Задача простая — сджойнить две таблицы — одна весьма большая, другая маленькая — но джоин не простой, а золотой с OR. (Как реальный кейс — джоин таблицы проводок по счетам к самим счетам, учитывая, что в проводке два поля со счетом — для дебета и кредита.)

Разработчик Oracle, часто использующий в коде регулярные выражения, особенно на базах с православными настройками, рано или поздно может столкнуться с явлением, которое, кроме как мистикой, никак не назовешь. Длительные поиски причин возникновения проблемы могут привести к потере веса, аппетита и спровоцировать различного рода психосоматические расстройства — все это я сейчас и попробую предотвратить. А поможет мне в этом функция regexp_replace. Она может иметь до 6 аргументов:

REGEXP_REPLACE (

1. исходная_строка,
2. шаблон,
3. заменяющая_строка,
4. позиция начала поиска совпадения с шаблоном (по умолчанию 1),
5. номер вхождения шаблона в исходную строку (по умолчанию 0 – все вхождения),
6. модификатор (пока что темная лошадка)

)
Возвращает измененную исходную_строку, в которой все вхождения шаблона заменены значением, переданным в параметре заменяющая_строка. Зачастую пользуются короткой версией функции, где заданы 3 первых аргумента, что бывает достаточно для решения многих задач. Я тоже так сделаю. Допустим, нам нужно в строке 'MASK: lower case' замаскировать все строчные символы звездочками. Для задания диапазона строчных символов должен подойти шаблон '[a-z]'. Проверяем

select regexp_replace('MASK: lower case', '[a-z]', '*') as result from dual

Ожидание

+------------------+
| RESULT           |
+------------------+
| MASK: ***** **** |
+------------------+

Реальность

+------------------+
| RESULT           |
+------------------+
| *A**: ***** **** |
+------------------+

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

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

Что такое гарантированный выбор в SQL? Допустим, что в условии запроса к таблице выполняется сравнение какого-либо поля с какой-нибудь переменной. В зависимости от значения этой переменной запрос может вернуть строки из таблицы, а может и не вернуть их вовсе. Если выпадает такое значение переменной, что строки из таблицы не возвращаются, то для этого случая надо специально сгенерировать заранее определенный левый результат. То есть в любом случае общий запрос должен гарантированно что-нибудь да вернуть. Сам термин взят отсюда. Однако задача усложняется тем (а может и наоборот, упрощается), что вместо одной простой ячейки со значением, нам нужно гарантировано вернуть полноценную строку.

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

Добро пожаловать в Голливуд. Представляю вам сегодняшних героинь



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

Создадим и заполним базовую таблицу

create table hollywood 
as 
with t (id, actress, husbands) as (
  select 1, 'Анджелина Джоли', 'Джонни Ли Миллер, Билли Боб Торнтон, Брэд Питт' from dual union all
  select 2, 'Шарлиз Терон', null from dual union all
  select 3, 'Пенелопа Крус', 'Хавьер Бардем' from dual
)  
select * from t;

alter table hollywood add primary key (id);

На носу зима, приближаются морозы, а это значит, что сегодня мы будем мариновать бананы. Для этого нам понадобятся следующие ингредиенты:

ID	INGREDIENT	MEASURE	QUANTITY
1	Банан	Штука	3
2	Петрушка	Ветка	2
3	Вода	Литр	3
4	Соль	Ложка	1
5	Уксус	Ложка	2

Я с удивлением обнаружил, что многие разработчики, даже давно использующие postgresql, не понимают оконные функции, считая их какой-то особой магией для избранных. Ну или в лучшем случае «копипастят» со StackOverflow выражения типа «row_number() OVER ()», не вдаваясь в детали. А ведь оконные функции — полезнейший функционал PostgreSQL.
Попробую по-простому объяснить, как можно их использовать.

В свете недавнего поста про сравнение PostgreSQL и MySQL, в комментариях возникла проблема выбора удобного интерфейса для работы с постгресом. Я сам столкнулся с такой проблемой, решив поискать альтернативы всем известному phpMyAdmin / php*Admin, который считается стандартом у веб-мастеров.

В последние годы NoSQL и BigData стали очень популярными в ИТ-индустрии, и на базе NoSQL успешно реализованы тысячи проектов. Часто на разных конференциях и форумах слушатели задают вопрос о том, как модернизировать или перенести старые системы (legacy) в NoSQL. К счастью, у нас был опыт перехода из SQL на NoSQL в крупном проекте СМЭВ 2.0, о котором я и расскажу под катом.

Изначально эта статья задумывалась только для разработчиков и администраторов СУБД Firebird, но после общения с администраторами других БД выяснилось, что большинство ошибок общие, и на очень похожие грабли наступают буквально все. Если Вы можете что-то добавить к этому списку (пусть даже специфическое для конкретной СУБД), пишите в личную почту или в комментариях.
In English: 12 Common Mistakes while Backing Up Databases

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

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

Итак, приступим.

Нынче модно делать API и многие из нас уже реализовывали какие-то API на PHP. Одна из задач REST API — отдавать наборы данных, чтобы их в конечном итоге отобразить в табличном виде. Для этого, помимо прочего, приходится решать такие задачи:

• провалидировать запрос,
• отфильтровать данные,
• отсортировать данные,
• запрашивать и отдавать не все колонки, а только некоторые,
• реализовать пагинацию.

Не знаю как вы, но я вижу, что часто это делается велосипедными решениями. Задачи с виду не сложные, но чтобы их решить качественно, приходится потратить немало времени на разработку, документацию и разъяснения коллегам, как работает ваше изобретение. Я расскажу о том, как можно реализовать эти задачи весьма технологично с помощью OData.

Firebird Project и компания IBSurgeon (IBase.ru) приглашают администраторов и разработчиков Firebird SQL, работающих с большими БД, на бесплатный семинар. Семинар пройдет 21 октября 2015 года в Москве. Для участия в семинаре необходимо приглашение — см. ниже.

Краткие темы семинара:

Многие из уважаемых читателей Хабра, интересующихся Firebird, знают, что в прошлом году вышла документация по языку Firebird SQL на русском языке версии 2.5. Создание документации спонсировала Московская Биржа (да-да, та самая, про курс рубля на которой мы слышим каждый день) — как платиновый спонсор и один из крупнейших пользователей Firebird в России, и компания IBSurgeon/IBase, представляющая Firebird в России.

Но на этом работа не закончилась:

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



Нет, я не буду рассказывать вам про MongoDB или ещё какую неполноценную «убийцу SQL». Статей на тему «SQL vs NoSQL» сравнивающих на самом деле реляционные субд с документными и так полно:

• MongoDB или как разлюбить SQL
• Реляционные базы данных обречены?
• NoSQL базы данных: понимаем суть
• Почему нужно 1000 раз подумать, прежде чем использовать noSQL
• SQL — гибок или почему я боюсь NoSQL
• NoSQL и Big Data – обман трудящихся?
• Чем поможет архитектору «NoSQL» и… поможет ли?
• Сравнение производительности MongoDB vs PostgreSQL. Часть I: No index
• Сравнение производительности MongoDB vs PostgreSQL. Часть II: Index
• Разбираем ACID по буквам в NoSQL
• Почему вы никогда не должны использовать MongoDB
• Почему мы выбрали MongoDB
• Недостатки RDBMS или RDBMS vs NoSQL
• Почему вы никогда не должны говорить «никогда»
• Еж с ужом в одной корзине, а также немного об отсутствии схемы
• Почему реляционные СУБД отлично подходят для стартапов: Пример из истории разработки мессенджера Kato
• Прощай, MongoDB, здравствуй, PostgreSQL

Но у большинства из них есть фатальный недостаток — авторы просто не в курсе, что моделей данных в СУБД есть куда больше, чем два упомянутых: от узкоспециализированных «словарей», то универсальных «графов». А популярные «реляционные» и «документные» находятся лишь где-то по середине между универсальностью и специализированностью.

Давайте сравним типичных представителей упомянутых типов СУБД (от большего к меньшему).

• Популярность: Oracle, MongoDB, Redis, HBase, OrientDB.
• Функциональность: OrientDB, Oracle, MongoDB, HBase, Redis.
• Скорость: очень сильно зависит от задачи, данных и реализации приложения. Я пересмотрел кучу бенчмарков, везде всё по разному.