SQL *

Есть немало книг, описывающих особенности и специфику конкретных БД.
Значительно меньше «программно-независимых» изданий, которые рассказывают об общих правилах и законах проектирования баз, принципах построения, нарушение которых может привести в дальнейшем к серьёзным ошибкам и проблемам. Где рассмотрена вся методологическая цепочка от постановки задачи до итогового анализа уровня целостности данных для каждого приложения.

Мы сейчас обсуждаем возможность издать на русском языке книгу Database Design for Mere Mortals: A Hands-On Guide to Relational Database Design и хотели бы включить в эту дискуссию «коллективный разум».

Уважаемые читатели! Пожалуйста, оцените это издание по пятибалльной шкале. Насколько оно раскрывает тему? Будет ли оно полезно разработчикам БД — лично вам, или, может быть, вашим менее опытным коллегам, которые смогут избежать ошибок проектирования?
Комментарии своей оценки, как всегда, приветствуются.

Не так давно мы анонсировали бесплатную утилиту SQL Dynamite для поиска по метаинформации в базах данных. Хотим поблагодарить всех за хорошие отызвы, критику, найденные ошибки.
Для вас мы выпустили обновление, исправили найденные ошибки, и добавили поддержку SQLite и Informix.

Новая версия доступна здесь.

В прошлой статье мы обещали рассмотреть вопросы доступа к метаинформации БД. Сегодня поговорим про MS SQL и Sybase.

Процесс поиска и анализа связей различных объектов в СУБД Microsoft SQL Server, Sybase Adaptive Server Enterprise, Sybase Anywhere и SQL Azure прежде всего заключается в работе с метаданными.

Проблема в том что Sybase ASE и MSSQL, изначально имея одинаковую структуру метаданных, прошли долгий путь развития независимо друг от друга. Sybase Anywhere изначально была Watcom SQL и имела кучу отличий от Sybase ASE, а SQL Azure – это вообще облачная СУБД. Тем не менее, структура метаданных в них во многом схожа, в частности имеют одинаковые названия таблицы, содержащие ключевую информацию об объектах (sysobjects, syscomments и syscolumns).

OrientDB — взгляд человека, который привык работать с реляционными базами данных.
Напомню, что OrientDB — графовая, документно-ориентированная база данных, реализованная на Java.

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

Возможность мгновенного оповещения об определенных событиях требуется достаточно часто. Системные администраторы должны как можно быстрее узнавать о сбоях в работе сервисов и серверов, технический персонал на производстве — о сбоях и отклонениях в технологическом процессе, службы оперативного реагирования — о происшествиях. Самый очевидный способ оповещения — это оповещение по СМС. Для оповещения через СМС существуют специальные интернет сервисы, осуществляющие рассылку сообщений на заданную группу. Можно сэкономить и осуществлять рассылку самостоятельно, используя GSM модем. Но у этого способа есть несколько минусов: нужно уметь работать с последовательным портом, а через него с модемом, последовательно обрабатывать команды; отправлять сообщения по-русски не так просто; скорость отправки большому количеству адресатов может оказаться не достаточно быстрой; сложно обеспечить контроль доставки; нет гарантии, что сотовый оператор не заблокирует сим карту, если посчитает рассылки за спам. В целом, сервисы рассылки дают хотя бы какие-то гарантии, но стоят определенных денег.

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

Совсем другое дело — системы обмена мгновенными сообщениями (ICQ, XMPP). Протокол XMPP оказывается более предпочтительным благодаря тому, что он открыт. А благодаря тому, что это полноценный сетевой протокол, то получаются «из коробки» доступны следующие возможности:

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

При желании список можно продолжить.

В качестве примера реализации данного подхода, разработана программа, которая оповещает об ошибках технологического оборудования. Стойка оборудования представляет из себя некую программу, которая пишет сообщения (и сообщения об ошибках в том числе) в базу данных. БД имеет формат — Paradox, а кодировка данных Win-1251. Было решено отказаться от графического интерфейса в пользу консольного приложения, параметры задавать текстовыми файлами. Инструмент для решения — QT.

Реализованный функционал: сбор ошибок с множества технологических установок, отправка сообщений через jabber, общий чат через jabber.

Очень часто за основу архитектуры приложения берётся дерево. Простой пример: есть страны, в странах — области, в областях — города, в городах — организации, в организациях — работники, товары или что-либо ещё. Использование дерева вполне логично и оправдано. Иерархичность такой системы показывает некая абстрактная таблица. Назовём её object:

CREATE TABLE object (
  id NUMBER(11),
  parent_id NUMBER(11),
  type VARCHAR2(16) NOT NULL,
  name VARCHAR2(255) NOT NULL,
  CONSTRAINT pk_object PRIMARY KEY (id),
  CONSTRAINT fk_object_parent FOREIGN KEY (parent_id) REFERENCES object (id) ON DELETE CASCADE ENABLE
);

Наполним её какими-нибудь данными:

id  |  parent_id  |  type     |  name
------------------------------------------------------
1   |  NULL       |  country  |  Россия
2   |  1          |  region   |  Московская область
3   |  1          |  region   |  Новосибирская область
4   |  2          |  city     |  Москва
5   |  3          |  city     |  Новосибирск

При этом мы можем легко одним запросом получать нужные нам связи:

-- Выбрать все города России
SELECT *
  FROM object
    WHERE type = 'city'
    START WITH id = 1 CONNECT BY PRIOR id = parent_id;

-- Выбрать страну, в которой находится Новосибирск
SELECT *
  FROM object
    WHERE type = 'country'
    START WITH id = 5 CONNECT BY PRIOR parent_id = id;

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

В данном топике хотелось бы поговорить о повышении производительности при работе с таблицами.

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

Как правило, это происходит из-за плохо спроектированной схемы – изначально не рассчитанной на оперирование большими объемами данных.

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

Привет, уважаемые Хабро-читатели и SQL-писатели. Команда ХостТрекера хочет поделиться полезной утилитой для SQL разработчиков и администраторов.

Какую задачу решаем?

Нахождение зависимостей объектов в БД.
Поиск по строке в метаданных БД (хранимых процедурах, View, пользовательских функциях, определениях таблиц, индексах, ключах)

В предыдущем посте была рассмотрена автоматизация процесса дефрагментации индексов. Теперь пришла очередь статистики.

Собственно для чего она нужна?

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

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

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

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

Среди подобных задач можно выделить следующие:

1. Дефрагментация индексов
2. Обновление статистики
3. Резервное копирование

Рассмотрим по порядку автоматизацию каждой из этих задач.

Увидев пост о LINQ на PHP, я решил незамедлительно поделиться своими наработками в этой области.
Моей реализации далеко до полноценного LINQ, но в ней присутсвует наиболее заметная черта технологии — отсутвие инородной строки запроса.

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

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

Предыдущий пост: Что такое Teradata?

Как Teradata распределяет строки?

• Teradata использует алгоритм хэширования для рандомного распределения строк таблицы между AMP-ами (преимущества: распределение одинаково, независимо от объема данных, и зависит от содержания строки, а не демографии данных)
• Primary Index определяет, будут ли строки таблицы распределены равномерно или неравномерно между AMP-ами
• Равномерное распределение строк таблицы ведет к равномерному распределению нагрузки
• Каждый AMP отвечает только за свое подмножество строк каждой таблицы
• Строки размещаются неупорядоченно (преимущества: не требуется поддержка сохранения порядка, порядок не зависит от любого представленного запроса)

Primary Key (PK) vs. Primary Index (PI)

Primary Key (первичный ключ) – это условность реляционной модели, которая однозначно определяет каждую строку.
Primary Index – это условность Teradata, которая определяет распределение строк и доступ.
Хорошо спроектированная база данных содержит таблицы, в которых PI такой же как и PK, а также таблицы, в которых PI определен в столбцах, отличных от PK, и может влиять на пути доступа.

Что такое физический дизайн структур хранения

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

Здравствуйте! И сразу прошу прощение, за слишком мудрёное название, но оно наиболее полно отражает излагаемый ниже материал.

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

Вычисление пересекающихся интервалов в линейном пространстве имен

Если у вас уже есть представление о пересечении интервалов, то пройдите сразу сюда.

Вычисление пересечений временных интервалов (отрезков времени) на прямой линии времени не составляет особого труда. Мы можем условно иметь пять видов временных пересечений.
Обозначим один отрезок времени как "\ \", а другой "/ /"

1. Смещение вперед по оси времени "/ \ / \"
2. Смещение назад по оси времени "\ / \ /"
3. Вхождение " / \ \ / "
4. Поглощение "\ / / \ "
5. Совпадение «X X»

Предисловие: По работе мне пришлось изучать устройство базы данных Teradata, и оказалось, что в интернете почти нет информации, особенно на русском языке. Поэтому я решила собрать в кучу всю доступную информацию.

Стремительное увеличение объемов носителей информации и удешевление стоимости хранения данных привело к появлению методов, способных обеспечить более быстрый доступ к необходимым данным – индексы, хранение данных в отсортированном виде и т.п. Эти методы вполне успешно справляются со своей задачей, однако возрастающая конкуренция в мире заставляет искать новые, более быстрые, способы доступа к информации. «Кто владеет информацией, тот владеет миром». Основной интерес вызывают базы данных с традиционной реляционной моделью данных, отвечающие требованиям ACID (Atomicity, Consistency, Isolation, Durability — атомарность, согласованность, изолированность, надежность) и предназначенные для аналитики Больших Данных (Big Data).

Teradata – это параллельная реляционная СУБД, которая работает на операционных системах:

• MP-RAS UNIX
• Microsoft Windows 2000/2003 Server
• SuSE Linux

Разнообразие поддерживаемых ОС — одна из причин, почему Teradata имеет открытую архитектуру.

Оригинал статьи носит название «10 SQL ошибок, которые делают Java разработчики», но, по большому счёту, приведённые в ней принципы можно отнести к любому языку.



Java программисты мешают объектно-ориентированное и императивное мышление в зависимости от их уровня:
— мастерства (каждый может программировать императивно)
— догмы (шаблон для применения шаблонов где-либо и их именование)
— настроения (применять истинный объектный подход немного сложнее чем императивный)

Но всё меняется, когда Java разработчики пишут SQL код.

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

SELECT *
FROM users
WHERE role_id=5
ORDER BY rand()
LIMIT 10

Такой код работает крайне медленно для больших таблиц.
Если в запросе не нужно использовать WHERE или таблица небольшая, есть эффективные решения, например habrahabr.ru/post/54176 или habrahabr.ru/post/55864.
Но готовых решений для большой таблицы и необходимости фильтровать по условию, получая при каждом запросе новые значения, я не нашел, поэтому описание моего способа под катом.

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

В синтаксисе T-SQL для выполнения подобного преобразования предусмотрена отдельная конструкция PIVOT. Стоит заметить, что в SQL Server 2000 поддержки конструкции PIVOT еще не было, поэтому аналогичные задачи решались через множественные CASE WHEN.

Собственно, почему я упомянул о CASE WHEN, если есть PIVOT? Ведь, по определению, PIVOT более элегантная конструкция и, соответственно, должна быть более эффективной.

Проверим это на практике…

Не секрет, что зашифрованные параметры (т.е. имеющие тип Encrypted), используемые в IBM DataStage в версиях до 8.7 очень легко расшифровать. Эти зашифрованные параметры часто используются для передачи паролей, необходимых для соединения с базами данных.
При постороении корпоративных ODS (а в некоторых случаях даже и в случае хранилищ данных) имеет смысл создавать универсальные джобы — так называемые генерики, которые полностью конфигурируются извне и не содержат специфичной для каждой таблицы информации, а поэтому их можно использовать для многих ETL процессов. Особенно это необходимо при извлечении данных из баз данных источников (Extraction). В таком случае необходимо хранить в файлах конфигураии пароли для каждого источника данных. И вам приходится, прогибаясь под политики безопасности различных предприятий, делать вид, что это надежный алгоритм шифрования и хранить пароли к корпоративным данным в зашифрованном DataStage виде.
Но проблемы возникают, если вы захотите передать такие параметры в джоб. Какие проблемы и как их решать я и напишу в этой статье.

Сначала результат, а потом разбор полетов. Допустим, вы создали запрос типа select [document].[id], [document].[name] from [SomeDocuments][document], но вместо ожидаемого

  id = 1
 name = d1

получаете

 document = 1
 document = d1

А теперь, если интересно будем разбираться.