Рубрика «sql» - 71

План обслуживания «на каждый день» – Часть 2: Автоматическое обновление статистики В предыдущем посте мы рассматривали автоматическое обслуживание фрагментированных индексов. Теперь пришла очередь статистики.

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

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

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

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

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

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

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»

Читать полностью »

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

10 потенциальных SQL ошибок, которые делают программисты

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

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

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

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

Такой код работает крайне медленно для больших таблиц и когда задается условие WHERE, без 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 виде.
Но проблемы возникают, если вы захотите передать такие параметры в джоб. Какие проблемы и как их решать я и напишу в этой статье.
Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js