Что-то не нашёл возможности указать в какой блокнот эверноута сбрасывать картинки. Печально.
Ещё бы возможность запускать Skitch по глобальному хоткею не помешала бы.
Да хотя бы тот факт, что скорость принятия решения программой в десятки раз больше, чем человеком, уже превозносит ПО над человеком. Какой бы вы не были аккуратный водитель, бывают случаи, когда вы просто не успеете среагировать, и тут уже вину не спишешь ни на какую программу.
Говорят, что ПДД пишуться кровью, но миллионы людей день изо дня нарушают их, преднамеренно или нет. Система управления автомобилем тоже, возможно, будет написана кровью, но правила, заложенные в ней, будут соблюдаться всегда, независимо от желаний и обстойтельств.
Собираюсь до нового года закончить ремонт в новой квартире, дизайн есть:
Техники пока никакой нет, но в качестве телевизора присматриваюсь к белому Philips с Ambilight. Белая аудиосистема, думаю, хорошо бы сочеталась с телевизором и в целом отлично бы вписалась в светлый интерьер. Да… неплохо бы смотрелось :) На конкурс
Одно мне не нравилось в мультиязычности в Друпале: когда редактируешь например немецкую ноду, весь UI на немецком, приходиться долго искать кнопку Сохранить. Даже если не влючать автоапдейт, многие модули тянут с собой переводы, в итоге в админском интерфейсе каша из разных языков. Для себя я нашёл такое решение — не использовать имеющиеся языки, а создавать свои: например Русский с кодом языка x-ru (по стандарту вроде бы кастомные языки должны именоваться x-...) и доменом ru. И всё, никто никогда не подтянет переводы для этих языков, и весь инрефейс всегда будет на английском независимо от языка редактируемой ноды. Придётся лишь вручную перевести текс некоторых элементов, который отображается на фронтэнде (например, Голосовать, и проч.)
В Оракле есть есть целая куча всего прочего, что Постгресу и не снилось. Истина, как известно, в деталях. И я считаю цену в полсотни килобаксов вполне оправданной. Другое дело, что далеко не всем нужна даже тысячная (а может и меньше) доля всех возможностей Оракла. Вот тут Постгрес и кстати.
Во-первых, произойдёт унификация образования множественного числа. Например, будем просто добавлять букву «а» к существительному со сдвигом ударения: корабла́, часа́, компьютера́.
Возможно я вас неправильно понимаю, но при adaptive cursor sharing как раз таки для одного и того же запроса (один sql_id) Оракл может сгенерировать несколько различных планов запросов в зависимости от значений параметров и статистики их распределения, в этом-то и прелесть ACS — запрос один, в планов может быть несколько.
Да, prepared statement-ы есть почти везде, но принцип работы везде разный.
Про постргрес уже написали выше, в Оракле когда-то было похожее поведение: план запроса вычислялся один раз, и для его генерации использовались первые параметры. Т.е. имея запрос: select col from tab where x = ?, и выполняя его впервые для x = 1, план строился именно для x = 1, и учитывал статистику распределения именно для x = 1. К примеру в таблице имеется только одна строка с x = 1 и миллион с x = 2. Для запроса с x = 1 оптимизатор выбрал доступ по индексу. Следующий запрос с x = 2 будет использовать доступ по индексу, несмотря на то, что значительно быстрее было бы сделать full table scan.
С появлением adaptive cursor sharing всё изменилось. Запрос с x = 2 опять будет тормозить, но только первый раз. После того как Оракл увидит, что актуальная статистика выполнения запроса сильно отличается от предполагаемой он создаст новую версию плана (старая при этом остаётся), и уже следующий раз запрос с x = 2 сделает full table scan, a x = 1 всё также будет делать поиск по индексу.
В общем есть ещё много чего, о чём хотелось бы рассказать про bind variables в Оракле, но комментарий будет слишком длинный.
Насчёт подстановок имён таблиц. Я бы не сказал что это странное поведение. К сожалению low-end базы данных не имеют номальных возможностей, например, партицирования таблиц, поэтому иногда приходится извращатся. Конечно это оправдано, если это вынужденная мера. Но часто это делают без особой необходимости, в большей степени это относится к PHP и MySQL, где средний процент «извращенцев», уж извините, больше чем где-либо (из моего опыта). Я бы сказал что это связанно с недостаточной квалификацией соответсвующих разработчиков, но боюсь меня закидают помидорами :)
Так много сказано про достоинства и почти ни слова про недостатки. Я мог бы многое рассказать про связываемые переменные в Oracle, но так как статья про MySQL (непонятно зачем в конце статьи дана ссылка на Кайта, ведь это совершенно разные СУБД), то поделюсь своими небольшими знаниями по теме топика, а именно по недостаткам, которые следует учитывать:
При использовании связываемых переменных (СП) не всегда работает кеш запросов, а именно: до версии 5.1.17 он вообще не использовался для запросов со СП, а после — используется при определённых условиях (How the Query Cache Operates).
Если запросы однократные, то СП только ухудшат произвотельность
Подготавливаться (prepare) могут только определённые запросы: кажется только DML + create table, а подставляться могут только значения, но никак не названия колонок, таблиц и проч. Поэтому если говорить про SQL-инъекции — СП не серебряная пуля, если у вас, например, динамически формируется название таблицы или колонки (например, заказы за 2012 год хранятся в таблице orders_2012, пользователь на сайте вводит год, и вы формируете название таблицы в виде «orders».$year)
Раньше были проблемы со связыванием списков, сейчас не в курсе. Т.е. у вас не получится связать "… WHERE X IN (?)" с массивом.
Ну и последний момент: в логах сохраняется запрос без подставленных значений, поэтому администрировать будет сложнее.
Я для таких целей чаще использую ant/maven. На вход параметры либо через коммандную строку либо через properties-файл, внутри вызывается sqlplus / sqlcmd / mysql / psql / whatever предварительно заменив все плейсхолдеры параметрами из конфига. Иногда используется комбинированный подход — maven'ом/ant'ом формируется, то что у автора называется par_file на базе параметров командной строки / ввёдных в интерактивном режиме значений / whatever, затем просто вызываются всё те же sqlplus / sqlcmd… В этом случае можно запускать как через ant/maven, так и без них, что удобно как для CI, так и для production версии.
Только не сочтите за рекламу. Вот сайт, который когда-то сделал на друпале. Там действительно практически ни строчки кода. Единственный нестандартный блок — это открытые сезоны (с десяток php строк). Админки как таковой нету, только управление стандартными модулями, но в связи с этим управлять сайтом не-программист не сможет — чтобы просто добавить материал нужно фиг знает куда лезть, не говоря уже про более сложные операции. Так что сложно считать сайт на друпале без строчки кода чем-то положительным.
Ещё бы возможность запускать Skitch по глобальному хоткею не помешала бы.
Говорят, что ПДД пишуться кровью, но миллионы людей день изо дня нарушают их, преднамеренно или нет. Система управления автомобилем тоже, возможно, будет написана кровью, но правила, заложенные в ней, будут соблюдаться всегда, независимо от желаний и обстойтельств.
Техники пока никакой нет, но в качестве телевизора присматриваюсь к белому Philips с Ambilight. Белая аудиосистема, думаю, хорошо бы сочеталась с телевизором и в целом отлично бы вписалась в светлый интерьер. Да… неплохо бы смотрелось :)
На конкурс
Это справедливо лишь для Oracle версии <= 10.2.0.1. Сейчас с этим, к счастью, дело обстаят получше.
Про постргрес уже написали выше, в Оракле когда-то было похожее поведение: план запроса вычислялся один раз, и для его генерации использовались первые параметры. Т.е. имея запрос: select col from tab where x = ?, и выполняя его впервые для x = 1, план строился именно для x = 1, и учитывал статистику распределения именно для x = 1. К примеру в таблице имеется только одна строка с x = 1 и миллион с x = 2. Для запроса с x = 1 оптимизатор выбрал доступ по индексу. Следующий запрос с x = 2 будет использовать доступ по индексу, несмотря на то, что значительно быстрее было бы сделать full table scan.
С появлением adaptive cursor sharing всё изменилось. Запрос с x = 2 опять будет тормозить, но только первый раз. После того как Оракл увидит, что актуальная статистика выполнения запроса сильно отличается от предполагаемой он создаст новую версию плана (старая при этом остаётся), и уже следующий раз запрос с x = 2 сделает full table scan, a x = 1 всё также будет делать поиск по индексу.
В общем есть ещё много чего, о чём хотелось бы рассказать про bind variables в Оракле, но комментарий будет слишком длинный.
Насчёт подстановок имён таблиц. Я бы не сказал что это странное поведение. К сожалению low-end базы данных не имеют номальных возможностей, например, партицирования таблиц, поэтому иногда приходится извращатся. Конечно это оправдано, если это вынужденная мера. Но часто это делают без особой необходимости, в большей степени это относится к PHP и MySQL, где средний процент «извращенцев», уж извините, больше чем где-либо (из моего опыта). Я бы сказал что это связанно с недостаточной квалификацией соответсвующих разработчиков, но боюсь меня закидают помидорами :)
$ mysql -u root -h 127.0.0.1 -P 3307 --prompt=«memsql> „
По сути там mysql база, которая вся держится в памяти.
Кстати, я вот подзабыл, неужели если база достаточно небольшая, mysql при должной настройке не сможет её так же целиком закешировать?