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

В двух словах JBoss Teiid – федеративная база данных [2]. Ну или так – это объединяющая реляционная надстройка над многочисленными источниками данных. С точки зрения пользователя такая база выглядит как единая схема, в которой таблицы, представления, и процедуры являются объектами внешних данных. Можно еще сказать что внешние данные транслируются в единую виртуальную базу.

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

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

Вступление

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

Есть много споров о плюсах и минусах 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

MSSQL и базы 1с 8.2

Здесь я опишу свои наблюдения, а также собранные с помощью гугла маленькие полезности для эффективной работы этих двух программных продуктов.
Всем известно, что хранить пользовательские базы нужно на отдельном диске, например вот здесь D:\Base. А так же желательно перенести на отдельный диск и файлы транзакций, например E:\Logs. Ну и раз уж мы говорим о переносе баз и логов на разные диски, то для увеличения производительности, нужно разнести их на разные физические диски. Дорого, скажете Вы, не совсем, в рамках предприятия это копейки, а головной боли будет меньше, хотя бы со свободным местом будет уже проще.
После всего этого будет целесообразно перенести и системные базы. Раньше я не задумывался об этом, но вот прижало. А дело было так. Доблестной бухгалтерии, накатили новую версию желтой программы, и все было замечательно до тех пор, пока не потребовалось им «закрыть месяц». Процедура длительная и поэтому оставляли ее на ночь. А с утра видели симпатичное сообщение об ошибке базы MSSQL. Расследование привело меня к тому, что на диске С:\ не оставалось свободного места. А именно, разрослись логии системных баз выше всякой меры. Было принято решение о переносе.

Исследователи из МТИ представили СУБД CryptDB, которая способна эффективно обслуживать запросы к БД SQL — поиск, сортировка, математические функции и др. — без расшифровки записей базы. Хотя это не первая разработка подобного рода, но благодаря беспрецедентной производительности эксперты считают CryptDB первой, реально пригодной для практического использования. Предполагается, что подобные разработки могут найти применения в системах облачного хранения данных, которые особенно нуждаются в криптографической защите.


^{Архитектура CryptDB}

Подход, реализованный в CryptDB, называется полным гомоморфным шифрованием. Первую полностью гомоморфную модель для СУБД предложил в 2009 году криптограф из IBM Research Крейг Джентри (Craig Gentry), она является гомоморфной для операций умножения и сложения одновременно, что даёт возможность выразить любую математическую функцию. Правда, была одна проблема: скорость операций по сравнению с обычной СУБД возрастала примерно в триллион раз.

Вступление

Несколько лет назад мне пришлось реализовать работу с таблицами базы данных MSSQL сервера. После написания некоторого количества, фактически однотипного кода, пришла мысль автоматизировать эти «рутинные» действия.
Согласитесь, что написание одного и того же кода, отличающегося только структурой таблиц БД, не может никого вдохновить. К тому же, если кол-во таблиц, с которыми приходиться работать переваливает за десяток, то занятие из разряда скучное — переходит в разряд трудоемкое.
Поиск в интернете на тот момент не дал результатов, поэтому реализацию пришлось взять на себя. .
В результате был создан набор модулей (в дальнейшем DigestSDK) на языке Delphi, позволяющих избавить программиста от написания «стандартного» кода по работе с БД и сосредоточиться на логике самого приложения. .
Демонстрационные примеры, исходные коды и видео по работе с DigestSDK выложил на SourceForge (авось еще кому да и пригодится, заодно и хабр эффект проверим в очередной раз:-))..