SQL *

Решил все-таки написать статью про SQLite, в которой хочу обобщить свой 3-х летний опыт использования этой БД под Windows. Вижу, что тема популярная, но информации мало.

Часть 2
Часть 3

Небольшая вводная.

Эта статья не для начинающих программистов.
Она не является учебником по SQL.
Она не агитирует использовать SQLite.
Она не агитирует не использовать SQLite.
Статья написана в виде вопросов от гипотетического новичка в SQLite и ответов на них (поскольку информации очень много и так хоть немного проще ее структурировать).

Недостаточно писать код хорошо читаемым: он также должен быстро выполняться.

Существует три базовых правила для написания такого T-SQL кода, который будет работать хорошо. Они кумулятивные – выполнение всех этих правил окажет положительное влияние на код. Пропуск или изменение любого из них – скорее всего приведет к отрицательному влиянию на производительность вашего кода.

• Пишите, исходя из структуры хранения данных: если вы храните данные типа datetime, используйте именно datetime, а не varchar или что-нибудь еще.
• Пишите, исходя из наличия индексов: если на таблице построены индексы, и они должны там быть, пишите код так, чтобы он мог использовать все преимущества, предоставляемые этими индексами. Убедитесь, что кластерный индекс, а для каждой таблицы он может быть только один, используется наиболее эффективным образом.
• Пишите так, чтобы помочь оптимизатору запросов: оптимизатор запросов – восхитительная часть СУБД. К сожалению, вы можете сильно затруднить ему работу, написав запрос, который ему «тяжело» будет разбирать, например, содержащий вложенные представления – когда одно представление получает данные из другого, а то из третьего – и так далее. Потратьте свое время для того, чтобы понять как работает оптимизатор и писать запросы таким образом, чтобы он мог вам помочь, а не навредить.

Существует несколько типичных ошибок, которые люди допускают в своем коде на T-SQL – не совершайте их.

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

В СУБД Caché такая интеграция осуществляется с помощью специального шлюза (Caché SQL Gateway), который использует в своей основе ODBC/JDBC соединения к внешним источникам данных. Причём под источником в данном случае можно понимать не только СУБД, так как есть JDBC/ODBC драйвера для MS Excel, DBF, текстовых файлов, графических файлов, WMI и т.д.

Caché Monitor

Если при разработке или использовании вашего приложения на Caché вам часто приходится выполнять SQL-запросы, а функциональности SQL-менеджера из Портала Управления Caché или SQL-оболочки из терминала Caché вам недостаточно, то советую обратить внимание на приложение Caché Monitor.

Альтернативный SQL-менеджер разработал Андреас Шнайдер — разработчик из Германии.
Это кроссплатформенное Java-приложение кроме выполнения SQL-запросов предоставляет следующие возможности:

Если бы мне пришлось писать книгу о том, как создавать немасштабируемые приложения Oracle, первая и единственная ее глава называлась бы «Не используйте связываемые переменные».
Том Кайт, вице-президент Oracle

Недавно на Хабре появилась статья от AlexanderPHP «SQL injection для начинающих. Часть 1». По ее содержимому и комментарием к ней может создаться впечатление, что у многих разработчиков нет понятия, что такое связываемые переменные, зачем ими следует пользоваться и какие преимущества они дают. Попытаюсь в данной статье пролить небольшой свет на данные вопросы.

 

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

Реляционная модель данных, предложенная в 1970 году Э.Ф. Коддом, надолго задала тенденцию в развитии баз данных и позволила полностью отвечать требованиям бизнеса до сегодняшнего момента. С 1970 года реляционные базы данных прошли большой путь и приняли много вызовов, встававших на их пути. Постоянно растущие объемы данных привели к появлению методов, способных обеспечить более быстрый доступ к необходимым данным – индексы, хранение данных в отсортированном виде и т.п. Эти методы вполне успешно справлялись со своей задачей, да и до сих пор не потеряли своей актуальности. Однако стремительное увеличение объемов носителей информации и удешевление стоимости хранения данных привело к тому, что объемы баз данных в десятки терабайт не являются уже чем-то необычным и воспринимаются, как обычное явление. Бизнес не может допустить, чтобы эти данные лежали «мертвым грузом», так как всё возрастающая конкуренция в мире заставляет его искать новые подходы к освоению сферы своей деятельности, ведь по крылатому выражению – «Кто владеет информацией, тот владеет миром». Если говорить о времени, то счет идет не на дни, или даже часы, а скорее на минуты – кто сможет быстро получить необходимую информацию, тот и выиграет.

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

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

Часть 3. Vertica. Simply Fast

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

Уже много статей в интернете есть про sql триггеры, но добавлю еще одну с адекватными примерами, что бы закрепить материал для тех, кто «в теме» и что бы лучше понять материал тем, кто только начал постигать «дзен sql». Заодно и создам дискуссию по теме.

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

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

Так что если вы собираетесь начать свое обучение в этой области или вам просто стало интересно, прошу под кат.

Если не успели все разобрать (интересно глянуть на тех, кто успел), текст можно посмотреть здесь.

Приветствую.

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

В этот момент у руководства могут возникнуть вопросы, если они не возникли ранее, что именно занимает так много места в БД, почему загрузка до сих пор не закончилась и прочее подобное.

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

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

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

Вступление

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

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

Я 5 лет разрабатываю платформу для ERP, разработал три версии платформы. Всё начиналось с EAV, после была нормальная модель, хранимые процедуры, view-хи, и сейчас эволюционировало до использования ORM. Позвольте поделиться опытом, почему ORM — хорошо.

Для демонстрации преимуществ такого подхода я разработал небольшое приложение для риэлтерского агентства (вдохновение черпал из Циан, из него же и модель данных) и попробую описать, почему благодаря ORM я все сделал за 1 день.

Я работаю разработчиком БД (MS SQL) и большая часть моей работы, это написание кода на T-SQL. Работая в Query Analyzer, а затем в Management Studio (2005, 2008, 2008R2) мне очень сильно не хватало функций редактора и дополнительных функций среды разработки, направленных именно на процесс написания кода, построения запросов и т.п… По сравнению с MS Visual Studio или Embarcadero RAD Studio, что мог предложить Query Analyzer? Изменить отступ блока кода, изменить регистр выделенного текста, закомментировать и отменить комментирование блока кода, перетащить название таблицы или поля (полей) в окно редактора, заскриптовать выбранный объект. А ведь так не хватало полноценного IntelliSense. Всех этих удобных функций по автодополнению, интерактивных подсказок к набираемому коду, выбор из списка объектов и т.п.

С выходом MS Management Studio 2005 ситуация не изменилась. И только в MS Management 2008 появился Transact-SQL IntelliSense. Да, появилось автозавершение набираемого слова, предоставление списка объектов БД и полей таблицы, подсветка синтаксических пар (begin… end, ()). Но уже до этого я стал пользоваться сторонней утилитой SQL Assistant от SoftTree Technologies. На фоне возможностей, которые предоставляет SQL Assistant родной IntelliSense просто дубовый. А разве можно получить что-то большего, ведь это SQL, а не объектно-ориентированный язык? Можно! В этой статье я хотел бы рассказать об утилите SQL Assistant, а точнее о функция и приемах, которые я использую при написании SQL-кода.

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

Пример требуемой сортировки: 8, 9, 10, 11, 12, Android 2.2, Android 2.3, BlackBerry

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

Гугл навёл только на какие-то страшные триггеры и регекспы.
Предлагаю вам предложить своё решение.

Моё решение (выделите текст, чтобы подсмотреть):
ORDER BY value=0, -value DESC, value

В конце декабря компания Oracle сообщила о падении своих акций на 9%. Но мне эта новость не показалась удивительной, потому что всего за пару дней до её появления я беседовал с Эдом Бояджаном (Ed Boyajian), президентом и CEO компании EnterpriseDB.

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