SQL *

Привет Хаброжители!
У нас вышло 6 переиздание книги



Прототип: Oracle PL/SQL Programming (Sixth Edition)
Paperback – March 3, 2014

Про результативность, качество и КПД сайтов знакомств можно спорить, можно искать 101 повод чем лучше в клубе/баре/_дополнить_варианты_/парке искать знакомства. То что еще лет десять-пятнадцать назад вызывало смех — теперь мейнстрим. Так не проще ли попытаться использовать еще одну возможность для поиска и общения в интернет с переходом к знакомству в жизни…



Гиковский вариант технологии поиска, скринкаст приложения под катом. В конце статьи ссылка на архив с работающим приложением под Apache License v2.0 и небольшим набором данных для примера.

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

24-25 октября 2014 года в Праге прошла международная конференция по СУБД Firebird. Присутствовало 110 участников, 18 докладчиков представили 23 интересных презентации.

Открывали конференцию ведущие разработчики СУБД Firebird Дмитрий Еманов и Влад Хорсун, с докладами о новых возможностях Firebird 3, который готовится к релизу в начале 2015 года, и Firebird 4 (2016). Наиболее важными новостями являются сокращение релизного цикла и фокус на отказоустойчивости и производительности.

Предисловие

Данная публикация — относительно вольный перевод опубликованоой в блоге Facebook статьи «Introducing osquery».

Введение в osquery

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

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

• запущенных процессах;
• загруженных модулях ядра;
• открытых стевых соединениях.

Facebook выложил на гитхабе фреймворк OSquery, он осуществляет низкоуровневый мониторинг процессов в OS X и Linux и хранит их в виде SQL-таблиц. Такой способ по-своему удобен, ведь в запросе можно объединять разные таблицы.

Например, если мы хотим посмотреть названия, pid и порты всех процессов, которые прослушивают порты во всех интерфейсах, то составляем запросик

SELECT DISTINCT 
  process.name, 
  listening.port, 
  process.pid
FROM processes AS process
JOIN listening_ports AS listening
ON process.pid = listening.pid
WHERE listening.address = '0.0.0.0';

Здравствуй, Хабр!
Предлагаю всем желающим вспомнить или познать суть блокировок движка InnoDB в MySQL.


КДПВ: deadlock в исполнении тропической фауны

По долгу службы мне приходится иногда проводить собеседования на позицию "[старший|младший] разработчик python/django", «тимлид». К моему великому удивлению я обнаружил, что 9 из 10 соискателей, в резюме которых значатся слова " Mysql/Innodb/transactions/triggers/stored proc etc.", абсолютно ничего не могут рассказать о своем прошлом опыте работы с ними. Ни одного описания варианта использования, к сожалению, я так и не получил.

Введение

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

Выполнение кода на JavaScript из кода, написанного на Java:

import javax.script.*;

public class InvokeScriptFunction {
    public static void main(String[] args) {
        ScriptEngineManager manager = new ScriptEngineManager();
        ScriptEngine engine = manager.getEngineByName("JavaScript");

        // JavaScript code in a String
        String script = "function hello(name) {print('Hello, ' + name);}";

        // evaluate script
        engine.eval(script);
    }
}

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

Условие задачи

Есть три бога: A, B и C, один из которых бог истины, другой – лжи, а третий — случая. Бог истины всегда говорит правду, бог лжи — всегда обманывает, бог случая может говорить и правду, и ложь. Требуется определить богов, задав 3 вопроса, на которые можно ответить «да» или «нет». Каждый вопрос задаётся только одному богу. Боги понимают язык, но отвечают на своём языке, в котором есть 2 слова «da» и «ja», причём неизвестно, какое слово обозначает «да», а какое «нет».

Если значительная часть бизнес логики Вашего приложения располагается в базе данных, вас наверняка посещала мысль о модульном тестировании хранимых процедур и функций. Опустим обсуждение вопроса о том, хорошо это или плохо — выносить логику в хранимые процедуры, и разберемся — как тестировать хранимый код. В этой статье я расскажу о tSqlt — замечательном бесплатном фреймворке unit-тестов с открытым исходным кодом для Sql Server.

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

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

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

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

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

Недавно мне случилось общаться с одним из ведущих профессионалов СУБД Oracle. Он рассказал много интересного про работу с планами выполнения запросов в различных версиях этой СУБД и не постеснялся рассказать всем об используемых им инструментах, приемах и дать немного полезных мелких советов. Я сделал перевод одной из статей в его блоге и хотел бы предложить его вниманию Хабравчан. Несмотря на то, что описанный прием применялся для работы с Oracle, я теперь с успехом применяю тот же подход для MS SQL и Sybase.

---

Меня зовут Дан Хотка (Dan Hotka). Я директор Oracle ACE. Одной из моих привилегий в этой группе является помощь в распространении информации и полезных технических знаний, связанных с СУБД Oracle. Меня хорошо знают после моих 12 (скоро 14) опубликованных книг и буквально сотен статей. Я регулярно пишу в блоге и собираюсь делать это в дальнейшем. Мы даже могли встречаться на одном из событий или встреч группы пользователей. Я регулярно выступаю на эти темы по всему миру.
Я собираюсь поделиться с вами как техническими знаниями про Oracle, так и тем, как эти знания применяются в решениях Embarcadero.

Довольно интересное видео (на английском, к сожалению), в котором девушка, на примере соцсетей, рассказывает о плюсах и минусах кэширования в web-приложениях.

Наиболее содержательными являются первые две трети ролика, которые можно суммировать следующим образом:

1) данных в соцсетях нынче много, обновляются они часто, а пользователю их нужно предоставлять быстро
2) поэтому без кэширования не обойтись
3) далее показывается, как кэширование (концептуально) работает в Twitter, Facebook и Reddit
4) но есть проблемка…
5) кэширование в каждом соцсетевом проекте отписывается вручную
6) в результате, имеем много кода, который делает практически одно и то же в каждом проекте. А много кода — это много багов и людского труда
7) и что же с этим делать?

Docsvision — это не просто программа, это платформа, позволяющая создавать свои решения для электронного документооборота. Статья нашего коллеги — разработчика Docsvision Димы Лейкина — предназначена как раз для разработчиков таких решений, к коим мы относим партнёров нашей компании и сотрудников IT-подразделений наших компаний-заказчиков.

В материале, разделённом на 5 логических частей, — базовая информация о том, как устроена система Docsvision. Кроме того, для разработчиков, которые хотят устроиться к нам на работу, эти знания будут дополнительным плюсом.

В любом обнаружении NoSQL баз данных кто-нибудь обязательно вспомнит о CAP-«теореме». Я не случайно пишу слово «теорема» в кавычках. CAP-«теорема» вовсе не теорема в математическом понимании этого слова. Это неформальное утверждение, сделанное Эриком Брюером в докладе на конференции Principles of Distributed Computing (PODC) в 2000 году. Эрик утверждал, что невозможно создать распределенное (состоящие из нескольких равноценных экземпляров — звеньев) веб-приложение, которое будет одновременно обладать тремя свойствами: согласованность (consistency), доступность(availability) и устойчивость к разделению(partition tolerance), сокращенно CAP. Неформальность утверждения заключается в том, что Брюер не дал определения этим трем понятиям.

Спустя два года Сет Гилберт и Ненси Линч опубликовали исследование, где дали определения понятиям CAP а также формализовали "отложенную согласованность" (Delayed Consistency), которую потом прозвали "согласованность в конечном счете" (Eventual Consistency) и доказали CAP-«теорему» в терминах указанных определений. Если вы еще не читали исследование, то это обязательно стоит сделать — lpd.epfl.ch/sgilbert/pubs/BrewersConjecture-SigAct.pdf

Эта «теорема» так бы и не была никому нужна, если бы её не взяли на вооружение маркетологи NoSQL.

Предыстория

Будучи «недомиддлом» в одной Харьковской конторе, я внезапно получил в LinkedIn приглашение переехать в Польшу и начать работать на один большой банк. После очень долгих раздумий я таки согласился, мотивируя себя надеждой, что это будет очень полезный опыт. Поработать на большую корпорацию это не только опыт программирования но и два, ато и три года полезных записей для резюме, а так же +100 к ношению костюма.(Как бы не так, но об этом в другой раз). Оказалось, что уровень говнокода в Польше намного привосходит оный в Украине, а средний уровень Senior девелопера, по крайней мере из тех кого я тут встречал, не идет ни в какое сравнение с украинскими коллегами.

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

Linq появился в 2007 году, тоже же появился первый IQueryable-провайдер — Linq2SQL, он работал только с MS SQL Server, довольно сильно тормозил и покрывал далеко не все сценарии. Прошло почти 7 лет, появилось несколько Linq-провайдеров, которые работают с разными СУБД, победили почти все «детские болезни» технологии и, уже пару лет как, Linq to Database (обобщенное название для популярных провайдеров) готов к промышленному применению.

Тем не менее далеко не все применяют Linq to Database и объясняют это не только тем, что проект старый и переписать на linq довольно сложно, но и приводят в качестве аргументов различные мифы. Эти мифы кочуют из одной компании в другую и часто распространяются через интернет.

В этом посте я собрал самые популярные мифы и опровержения к ним.

Дисклеймер: Под Linq to Database здесь и далее понимаем самые распространенные .NET библиотеки для доступа к реляционным СУБД с использованием Linq запросов. Такие как Linq2SQL, Entity Framework, NHibername, Linq2db и подобные

С момента появления IQueryable провайдеров для доступа к базам данных писать запросы стало гораздо легче. С одной стороны это хорошо, потому что приложения стало делать гораздо легче. С другой стороны качество запросов сильно упало. И дело не в том, что провайдеры генерируют плохой SQL, а в том, что люди пишут запросы, не понимая как оно работает под капотом. Для многих C# программистов IQueryable является магией, и появляется естественное желание уменьшить влияние магии на приложения, изолировать магию от остального кода. Такой подход не только не исправляет ситуацию, а усугубляет её…

Ни для кого не секрет, что в Java EE Connection Pool реализуется используя Data Source. С примером реализации в Apache Tomcat можно ознакомиться по этой ссылке: habrahabr.ru/post/101342. Но что делать, если мы используем только Java SE и нам нужно организовать многопоточный доступ к базе данных по схеме Connection Pool. Ведь сервера приложений у нас в данном случае нет, следовательно, использовать Data Source мы не можем, а для создания соединений к бд нам придется скорее всего использовать java.sql.DriverManager. Можно еще использовать в замену данному подходу что-нибудь из этой статьи: docs.oracle.com/javase/jndi/tutorial/ldap/connect/pool.html. Скорее всего кем-то данный подход уже реализовывался на Java, по крайней мере я не обнаружил такую реализацию в сети. И я решил изобрести свой велосипед. Было бы хорошо, если в поисковике при поиске Connection pool в Java выходила ссылка на эту статью, дополненную и отредактированную по комментариям и дополнениям от habr.ru, и эта статья была бы полезна кому-нибудь. Если стало интересно, то прошу под кат.