SQL *

Эта статья — частичный перевод одной интересной статьи с sqlite.org, в которой подробно рассматривается реализация транзакций в SQLite. На самом деле я очень редко работаю с SQLite, но тем не менее мне очень понравилось это чтиво. Поэтому если хотите просто развить кругозор — будет интересно почитать. Первые две секции не включены в перевод, так как там нет ничего интересного, да и мне лень их набивать (пост и так огромный).

3.0 Однофайловый коммит

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

3.1 Начальное состояние

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

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

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

Начало см. часть 1, часть 2.

Вторичные индексы

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

В MUMPS индексы обслуживаются явно программистом, например, в функции обновления таблицы.

В январе месяце этого года мы анонсировани книгу Сергея Тарасова "Дефрагментация мозга. Софтостроение изнутри" (http://habrahabr.ru/company/piter/blog/165327).
Прошло положенное время и книга вышла в свет.

Известно, что встроенная функция newID() широко используется разработчиками не только по прямому назначению — то есть для генерации уникальных первичных ключей, но и в качестве средства для генерации массивов псевдослучайных данных.

Начало см. часть 1.

Глава 2. SQL/реляционные БД против MUMPS

В этой главе будут изложены основные различия между обычными SQL реляционными базами данных и БД на основе MUMPS.

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

Данной статьей хотелось бы показать шаги и предложить некоторые рекомендации в процессе создания BI-решения с использованием практически всего стека BI компании Microsoft. В создании BI-решения будут использованы SQL Server, SQL Service Integration Services, SQL Server Analysis Services.

Для примера мы выбрали разработку нашей компании RetailIQ — BI-систему глубокого анализа чеков розничных продаж, поставок и складских запасов для сети аптек. Для общего понимания контекста темы: все данные выгружаются из учетных систем (1С, М-Аптека и т.д.), верифицируются, складываются в специальную базу данных с последующим построением многомерных OLAP-кубов. Из источников (учетных систем) с помощью ETL мы перекачиваем данные в хранилище, на основе которого строим куб, о котором дальше пойдет речь.

Всем привет, недавно задался идеей написать PHP движок для своих нужд, так сказать и уровень повысить и получить что-то полезное. Почти сразу задался вопросом, а на сколько легко можно будет его взломать? Не секрет, что взломать можно все, что угодно, но вопрос в том, на сколько это будет проблематично и каждый ли хакер сможет это сделать?

Формы

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

foreach( $_POST as $item ){}

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

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

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

Всем доброго времени суток. Хотелось бы поделиться интересным, на мой взгляд, опытом работы с SQLite.

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

До недавнего времени все СУБД, работающие со структурированными данными (и не только их), можно было разделить на 2 категории: хранящие записи в построчном формате и хранящие записи в поколоночном формате. Это фундаментальное отличие, влияющее на то, как строки таблиц выглядят на уровне внутренних механизмов хранения СУБД. Долгое время СУБД Teradata относилась к первой группе, но с выходом 14-й версии представилась возможность определять, как хранить данные конкретной таблицы – в виде колонок или строк. Таким образом, появилось гибридное хранение. В этой статье мы хотим рассказать о том, зачем это нужно, как это реализовано и какие преимущества дает.

Рассказывая людям на встречах и презентациях про технологию, относящуюся к области баз данных, я поражаюсь, какая огромная пропасть может быть между тем, чем человек занимается и в какой области он работает. Еще больше поражает, что такая пропасть может присутствовать и у технических специалистов. Я попробую пояснить – например, в карточке человека написано «Специалист по работе с базами данных», а на деле оказывается, что этот человек умеет настраивать бэкапы в RMAN-е, создавать индексы и перестартовывать инстансы. Все его знания в области баз данных умещаются в знание, как использовать эти три инструмента. Ах да, еще, конечно же, знание SGA. Поразительно, но возникает такое чувство, что человек определил себе рамки, в границах которых он что-то знает, а что происходит за этими рамками, ему кажется неинтересным и недостойным внимания.

«Распределение нагрузки MSSQL на 2 сервера»

Добрый день, хабражители, вот решил написать про свою историю «Распределение нагрузки MSSQL на 2 сервера методом двунаправленной транзакционной репликации данных». Да не просто 2 сервера, а что бы работали они как зеркала. Кого заинтересовало, приглашаю к чтению.

Навеяно недавним постом.

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

Хочу написать мини-обзор о совсем не новом, но верном помощнике — SQL Power Architect'е. Опенсорсном кроссплатформенном приложении написанном на java, с поддержкой различных БД.

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

7. Производительность скалярных UDF оставляет желать лучшего

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

Посмотрите этот пост о принудительном использовании параллелизма – в частности, список того, что приводит к генерации «однопоточного» плана выполнения запроса. Скорее всего, использование скалярных UDF (прим. переводчика: а для серверов младше 2008 R2 и не только скалярных) приведёт к тому, что ваш запрос будет выполняться в одном потоке (*грустно вздыхает*).

Так сложилось, что по долгу службы столкнулся со следующей задачей: нужно было быстро и как можно проще сгенерировать много REST-сервисов. Мне казалось, что должно существовать немало решений, этой не такой уж и сложной задачи. И каково было мое удивление, когда пошарив по бескрайним просторам Интернета, нашел всего лишь пару подходящих продуктов. Среди наиболее подходящих мне отобрал Rest4Enterprise, restSQL и IBM Web API Services (может кто еще какие знает? you are welcome!). restSQL показался совсем хиленьким, продукт от IBM – наоборот, мощнейшим зверем. Поэтому придерживаясь правила «золотой середины», решил опробовать Rest4Enterprise. Продукт еще совсем новый (январь 2013), информации по нем, кроме официального источника нет вообще, поэтому решил поделиться с хабрачитателями своим небольшим опытом работы с ним.

5 февраля компания Oracle анонсировала выпуск стабильного релиза MySQL версии 5.6. В новой версии проделана огромная работа. Основные усилия были направлены на повышение производительности, масштабируемости и гибкости. Масштабным по значимости изменениям подвергся движок InnoDB.

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

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

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

Таблица игр чемпионата

Основная хранимая процедура — это процедура формирования игр чемпионата между командами. При формировании я придерживался основных правил турнира:

• Количество команд участвующих в турнире должно быть четным;
• Каждая команда должна сыграть с другой 2 раза — на своем стадионе и на стадионе соперников;
• В одном туре одна и та же команда может играть лишь один раз;
• За победу в матче команда получает — 2 очка, за ничью — 1 очко, а за проигрыш соответственно — 0.

Давайте поэтапно рассмотрим алгоритм формирования таблицы игр. Логику буду стараться описывать детально, не скучно и с демонстрацией схем. Как пример давайте возьмем чемпионат в котором участвуют 4 команды, хотя алгоритм может работать с любым четным количеством команд. Условно давайте обозначим наши команды под номерами 1, 2, 3 и 4, которые в моей реализации являются их прямыми ID.

«There are three kinds of lies: lies, damned lies, and statistics» Бенджамин Дизраэли, 40-й премьер-министр Великобритании

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