• подсветка и автокомплит например, CSS внутри HTML внутри JS внутри PHP.
• навигация по CSS
• именованные пачки вкладок (tasks) интегрированные с контролем версий и багтрекером
• лучший в мире GUI к Git (насколько вообще возможен GUI к этому поделию) и интеграция с Github.
• Несколько VCS в проекте в любых сочетаниях любой вложенности с несколькими «корнями»
• PhpStorm работает быстрее NetBeans for PHP.
• поддержка PHPUnit (Status GUI, Go to test итп)
• лучший в мире commit dialog (ввод коммента и полноценная правка исходников прямо из просмотра diffа)
• рефакторинги вроде rename var/field/class (последний переименовывает заодно и файлы с классом и тестами), extract|inline variable, extract method итп.
• идеальная реализация VCS history
• лучший в мире редактор Javascript (автокомплит, рефакторинг, поддержка популярных фреймворков ипр.)
• лучшая в мире реализация local history
• визуальное слияние изменений файла внешней программой
• управление кодировкой на уровнях проек/папка/файл (netbeans — кодировка одна на весь проект);
• быстрое форматирование кода на больших файлах
• цветные вкладки, раскрашиваемые по путям, которые можно задавать регулярками. Контроллеры, модели и вьюхи разными цветами
• в результатах поиска можно тыкнуть на строчку — в окне рядом появится участок кода. Не надо открывать файл, чтобы посмотреть
•  подсветка неиспользуемых переменных
• куча клавиатурных сочетаний

Исходный код

Integer taskId = sqlFactory.select(ID).from(TASK).where(STATUS.equal(TaskStatus.QUEUED)).
    orderBy(LAST_UPDATED).limit(1).fetchOne(ID);

Как видите, конструирование запроса и его выполнение для простых типов занимает одну строку. Немного о jooq:

Что у нас хорошего?

• Поддержка MySQL 5.1.41 / 5.5.8, Oracle XE 10.2.0.1.0, DB2 9.7, PostGreSQL 9.0, H2 1.3.154, HSQLDB 2.1.0, SQLite, Derby 10.7
• Планируется поддержка Sybase, MSSQL, Ingres, Firebird
• Поддержка генерации кода не только для таблиц / полей, но и представлений, хранимых процедур, UDF, сложных типов вроде ENUM в MySQL, Blob (можно представить их в виде обычных byte[])
• Поскольку вся схема базы данных представлена классами, в нормальных IDE (и даже в тех, что не очень) работает автозавершение языковых конструкций
• Отсутствие уязвимости SQL Injection при правильном использовании – jooq пользуется шаблонами параметров в запросах
• По большей части независимый от базы данных синтаксис
• Использование обобщенных типов обеспечивает достаточное количество проверок еще при компиляции кода. Плюс невозможно забыть исправить какой-либо кусочек кода, если вы вдруг переименовали столбец в таблице БД. После повторного парсинга БД некорректный код просто не скомпилируется
• Базовая поддержка ActiveRecord (полученную из базы данных запись можно изменить и записать назад одним-двумя строчками)
• Поддержка не только SELECT запросов, но и INSERT, UPDATE.
• Поддержка вложенных запросов, произвольных полей, агрегатных функций, UNION запросов, арифметических и других операций
• Удобные методы получения результатов выполнения запроса – fetch(), fetchAny(), fetchLazy(), fetchMap() и другие.
• Хорошая поддержка SLF4J в том числе и для профайлинга внутреннего устройства Jooq.
• Много чего запланировано
• Автор постоянно в интернете, очень оперативно отвечает на вопросы в jooq Google Group и на тикеты в баг-трекере.
• Поддержка Maven. Дистрибутивы jooq доступны через Maven Central.
• Поддержка как DSL синтаксиса (select().from().where()) конструирования запросов, так и ООП (a=new Query(); a.addSelect(); a.addFrom())
• Результаты запросов и сами объекты запросов сериализуемы.

Что у нас плохого?

• Пока нет непосредственной поддержки некоторых специфичных языковых возможностей вроде «FOR UPDATE» или «index usage hints»конструкций в SELECT. Но есть workaround.
• Если вы работаете в одном классе более чем с одной таблицей, import static в некоторых случаях использовать затруднительно, что приводит к некоторому усложнению внешнего вида запроса (пример по отношению к тому, что указан сверху):

Исходный код

Integer taskId = sqlFactory.select(Task.ID).from(Task.TASK).where(Task.STATUS.equal(TaskStatus.QUEUED)).
    orderBy(Task.LAST_UPDATED).limit(1).fetchOne(Task.ID);

• Небольшой оверхед при исполнении запросов и обходе результата (думаю, он небольшой, десятки-сотни микросекунд, может быть?)
• Пока нет непосредственной поддержки LAST_INSERT_ID() в MySQL. Но есть workaround. Sequences поддерживаются.

Субъективности

• Кода пока нет на GitHub , основная разработка ведется в Subversion
• SourceForge страницы проекта слегка тормозят, что немного раздражает.
• Мануал вроде бы достаточно подробен, но некоторые простые, но полезные вещи в нем отсутствуют. Он также показался мне не слишком удобным. В нем описано только самое основное без «фишек», «плюшек» и удобностей. Впрочем, если у вас большой стаж Java, наверное, до всего можно и самому быстро дойти. Кроме того, мне показалось, что он не слишком хорошо структурирован. Информация по нему размазана. Я всегда тороплюсь и хороший мануал для меня must-have…
• Не слишком удобный синтаксис для работы с агрегированными полями (во всяком случае, я по-другому пока не придумал, как можно это сделать удобно)

Исходный код

Field<Integer> jobTypeCountField = Job.JOBTYPE_ID.count().as("JOBTYPE_ID_COUNT");
 
Result<Record> jobTypeCountRecord = null;
jobTypeCountRecord = sqlFactory.select(Job.JOBTYPE_ID, jobTypeCountField).from(Job.JOB)
    .where(Job.STATUS.equal(JobStatus.EXECUTING)).groupBy(Job.JOBTYPE_ID).fetch();
for (Record record : jobTypeCountRecord) {
    System.out.println(record.getValue(Job.JOBTYPE_ID) + " - " - record.getValue(jobTypeCountField));
}

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

• В версии 2.0 запланированы очень интересные плюшки.
• Не-wiki документация (Trac) и не слишком удобная по ней навигация. Впрочем, в коде достаточно javadoc чтобы все понимать по Ctrl-Q. Впрочем, просто я считаю Trac не слишком удобным, вот и придираюсь…
• Пока сравнительно небольшое количество пользователей.

Аналоги jooq

• Querydsl
• SQL Construction Kit (документации по нему найти не удалось)

Контакты:

• Сайт проекта – http://www.jooq.org
• Мануал: http://sourceforge.net/apps/trac/jooq/wiki/Manual
• Форум – http://groups.google.com/group/jooq-user
• SVN Info: https://sourceforge.net/scm/?type=svn&group_id=283484

Несколько примеров из исходников Jooq (работа с базой information_schema в MySQL)

Исходный код

select(KeyColumnUsage.CONSTRAINT_NAME, KeyColumnUsage.TABLE_NAME, KeyColumnUsage.COLUMN_NAME)
                .from(KEY_COLUMN_USAGE).join(TABLE_CONSTRAINTS)
                .on(KeyColumnUsage.TABLE_SCHEMA.equal(TableConstraints.TABLE_SCHEMA))
                .and(KeyColumnUsage.TABLE_NAME.equal(TableConstraints.TABLE_NAME))
                .and(KeyColumnUsage.CONSTRAINT_NAME.equal(TableConstraints.CONSTRAINT_NAME))
                .where(TableConstraints.CONSTRAINT_TYPE.equal(constraintType))
                .and(KeyColumnUsage.TABLE_SCHEMA.equal(getSchemaName()))
                .orderBy(KeyColumnUsage.TABLE_NAME.ascending(), KeyColumnUsage.ORDINAL_POSITION.ascending()).fetch()

Исходный код

for (Record record : create().select(
                    ReferentialConstraints.CONSTRAINT_NAME,
                    ReferentialConstraints.TABLE_NAME,
                    ReferentialConstraints.REFERENCED_TABLE_NAME,
                    ReferentialConstraints.UNIQUE_CONSTRAINT_NAME,
                    KeyColumnUsage.COLUMN_NAME)
                .from(REFERENTIAL_CONSTRAINTS)
                .join(KEY_COLUMN_USAGE)
                .on(ReferentialConstraints.CONSTRAINT_SCHEMA.equal(KeyColumnUsage.CONSTRAINT_SCHEMA))
                .and(ReferentialConstraints.CONSTRAINT_NAME.equal(KeyColumnUsage.CONSTRAINT_NAME))
                .where(ReferentialConstraints.CONSTRAINT_SCHEMA.equal(getSchemaName()))
                .orderBy(
                    KeyColumnUsage.CONSTRAINT_NAME.ascending(),
                    KeyColumnUsage.ORDINAL_POSITION.ascending())
                .fetch()) {
 
            String foreignKey = record.getValue(ReferentialConstraints.CONSTRAINT_NAME);
            String foreignKeyColumn = record.getValue(KeyColumnUsage.COLUMN_NAME);
            String foreignKeyTableName = record.getValue(ReferentialConstraints.TABLE_NAME);
            String referencedKey = record.getValue(ReferentialConstraints.UNIQUE_CONSTRAINT_NAME);
            String referencedTableName = record.getValue(ReferentialConstraints.REFERENCED_TABLE_NAME);
 
            TableDefinition foreignKeyTable = getTable(foreignKeyTableName);
 
            if (foreignKeyTable != null) {
                ColumnDefinition column = foreignKeyTable.getColumn(foreignKeyColumn);
 
                String key = getKeyName(referencedTableName, referencedKey);
                relations.addForeignKey(foreignKey, key, column);
            }
        }

1. Открываем library\XenForo\Dependencies\Public.php и заменяем метод getJquerySource на такой (просто добавляем еще один case фактически):

Исходный код

/**
	 * Fetch the path / URL to the jQuery core library
	 *
	 * @param boolean $forceLocal If true, forces the local version of jQuery
	 *
	 * @return string
	 */
	public static function getJquerySource($forceLocal = false)
	{
		$jQueryVersion = XenForo_Application::$jQueryVersion;
		$min = '.min';
 
		// CDN sources from http://docs.jquery.com/Downloading_jQuery#CDN_Hosted_jQuery
		$source = ($forceLocal ? 'local' : XenForo_Application::get('options')->jQuerySource);
		switch ($source)
		{
			case 'jquery':
			case 'mt':
				return "http://code.jquery.com/jquery-{$jQueryVersion}{$min}.js";
 
			case 'google':
				return "http://ajax.googleapis.com/ajax/libs/jquery/{$jQueryVersion}/jquery{$min}.js";
 
			case 'microsoft':
				return "http://ajax.microsoft.com/ajax/jquery/jquery-{$jQueryVersion}{$min}.js";
 
			case 'yandex':
				return "http://yandex.st/jquery/{$jQueryVersion}/jquery{$min}.js";
 
			default:
				return "js/jquery/jquery-{$jQueryVersion}{$min}.js";
		}
	}
}

2. В Debug режиме идем в панель управления, находим там опцию jQuery Source (CDNjQuery) в разделе Performance (Производительность) и нажимаем карандашик справа (редактирование). Format Parameters (Параметры формата) заменяем на:

local=Local
google=Google Ajax API CDN
jquery=jQuery CDN
microsoft=Microsoft CDN
yandex=Яндекс CDN

Вот и все.  Теперь в настройках форума можно выбрать Яндекс CDN и jQuery будет загружаться с Яндекса. Только не забудьте отключить Debug режим.

^(([a-zA-Z0-9_\-\?]+)|(((\xD0[\x80-\xBF])|(\xD1[\x80-\xBF])|([0-9_\-\?]))+))$

Вот она такая получилась. Обратите внимание, что пробелы запрещены. Если требуется их разрешить, можно добавить после 0-9 \x20.

Начальные условия такие: мы рассматриваем примеси, имеющие свое состояние и имеющие доступ ко всем членам класса-агрегатора. Все публичные члены класса примеси становятся частью агрегатора. Мы оставляем за кадром вопрос быстродействия.

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

Данная статья в некотором роде является логическим продолжением этой статьи о реализации примесей в PHP. Если вам интересно – прочтите. Если нет, это не будет проблемой для понимания излагаемого тут материала.

Образцы кода

Сначала рассмотрим различия двух подходов на примере кода, делающего одно и то же.

Примесь

Исходный код

class Aggregator { }
 
class Mixin {
    public function doSomething() {}
}
 
Mixins::mix("Aggregator", "Mixin");
 
$a = new Aggregator ();
$a->doSomething();

Делегирование

Исходный код

Class Aggregator {}
 
class Mixin {
    public function doSomething() {}
}
 
class AggregatorMixed extends Aggregator {
    private $mixin;
 
    function __construct() {
        $mixin = new Mixin();
    }
 
    public function doSomething() {
        $mixin->doSomething();
    }
}
 
$a = new AggregatorMixed ();
$a->doSomething();

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

Технические различия

Чем же отличаются два фрагмента с технической точки зрения? Они обеспечивают одинаковый функционал, как видите.

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

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

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

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

Еще одно небольшое следствие состоит в том, что в случае с делегированием, решение по объему делегируемого функционала принимает класс-агрегатор, в случае с примесями – сама примесь.

3.       Примесь автоматически имеет доступ ко всем членам класса-агрегатора и может им произвольно манипулировать, при условии, что знает, как он устроен.  В случае делегирования этого доступа нет.

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

Теперь давайте посмотрим, как одни и те же возможности можно реализовать примесями и делегированием.

Пример «Поведение в ORM».

Мы сделали на нашем вымышленном фреймворке небольшой сайт. На этом сайте есть каталог статей. Наш фреймворк содержит ORM, в котором есть модель «статьи». В наш ORM также входят классы, поддерживающие распространенные модели поведения: дерево, версионность, мягко-удаляемость и так далее.

Предположим, что нам нужно сделать каталог статей древовидным в следующей версии нашего фреймворка. Что мы делаем? Мы добавляем модель поведения «дерево» в класс модели «статья». Мы можем выбрать либо примесь, либо делегирование в этом случае. Результаты будут напоминать те примеры, что мы рассматривали в самом начале. Обратите внимание на один момент. В случае использования примеси видимый интерфейс основного класса не изменился совсем, а в случае делегирования он только расширился, но все равно остался совместимым.

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

Обратите внимание, что в этом примере возможно использование как примесей, так и делегирования.

Теперь давайте рассмотрим аналогичный пример, только теперь в модель функционал добавляем не мы, а плагины к нашему фреймворку, которые пишутся сторонними разработчиками. От нас требуется только предоставить удобный API, чтобы для интеграции плагина в систему не пришлось переписывать большую ее часть.

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

Но авторы плагинов «версионности» и «мягкоудаляемости» хотят, чтобы эти возможности добавлялись в модель статей не «вместо», а «вместе»! Как это можно реализовать? В случае примесей все по-прежнему просто. Мы подмешиваем в класс модели новый и новый фунционал. А с делегированием? По-видимому, тут схема начинает усложняться. Нам нужно, чтобы классы плагинов наследовались друг от друга, а класс первого плагина – от оригинального класса модели. С определенными затратами такой функционал тоже можно добавить. Что для вас предпочтительнее, должны решить вы сами.

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

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

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

Помните, что любой выбор в жизни всегда нужно делать, руководствуясь двумя вещами: максимальным количеством информации, которое вы можете собрать по данному вопросу и собственной головой. Я постарался предоставить первое. Второе – за вами. С опасением относитесь к ссылкам на авторитеты. Руководствуйтесь изречением Спинозы: «ссылки на авторитет – не есть довод». Все и всегда проверяйте.

P.S. Если данная статья показалась вам интересной, предложите в комментариях тему для следующей.

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

Я сомневаюсь, чтобы кто-то из нас двоих с Леонидом ставил себе задачу универсальной реализации примесей в проектах любой величины. Обе наши реализации, мне кажется, не выходят далеко за уровень домашних фреймворков и представляют собой скорее концепт реализации примеси без eval(), нежели рабочий инструмент. Но, тем не менее, давайте попробуем погрузиться в сравнение.

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

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

И я, и Леонид, похоже, допустили одну и ту же ошибку в реализации, связанную со сборкой мусора. Обратите внимание на циклические ссылки: в классе-агрегаторе хранятся ссылки на экземпляры классов примесей, и в примесях, в свою очередь, хранятся ссылки на экземпляры классов агрегаторов. В PHP версиях младше 5.3 произойдет утечка памяти, потому что сборщик мусора не умеет работать с циклическими ссылками. В 5.3 можно активировать специальный сборщик мусора для этой цели, но он замедляет работу скрипта в целом, так что это нежелательно. Что в этом плохого? Все зависит от того, для чего и как используются примеси. Если объектов-агрегаторов со своими примесями много, они большие и сложные, часто создаются / разрушаются – все будет очень плохо. Если же примеси подмешиваются к агрегаторам, существующим на всей протяженности жизни скрипта, ничего страшного не будет, так как вся занимаемая скриптом память при его завершении будет освобождена принудительно.

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

Сейчас вот оказалось, что вариант Леонида вообще не компилируется, потому что магический метод __call() в классе Caller не может быть защищенным. Исправил, заработало. В 5.3 варианте из комментария этой ошибки уже нет.

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

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

Примеси в варианте Леонида реализуются исключительно наследованием. В моем варианте композиция, наряду с наследованием, тоже доступна. Иногда это полезно, если класс невозможно унаследовать от класса-агрегатора.

За счет «подсоединения» в моем варианте примеси можно подсоединять к классам прямо в процессе исполнения основного кода. То есть, если потерять осторожность, может оказаться так, что в один экземпляр класса данная примесь подмешана, а в другой нет. Мы получили чрезмерную гибкость, которую легко устранить, если это необходимо. Кстати,  это можно сделать, исследуя кэш (реестр).

Вариант Леонида реализует не все магические методы у класса-агрегатора (основной акцент сделан на методах), но это легко исправить.

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

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

У Леонида возникает еще одна любопытная ситуация, если в примеси определить защищенный или приватный метод с каким-либо именем, а затем попытаться вызвать метод с этим именем на агрегаторе. Обратите внимание на граф вызовов. У агрегатора вызывается __call(), идет поиск метода с заданным именем среди методов примесей с помощью method_exists(). Совпадение обнаруживается, поскольку method_exists() для скрытых и защищенных членов тоже возвращает true. Производится попытка вызова этого метода уже на экземпляре примеси. Поскольку метод все же защищенный и из данной области видимости недоступен, вызывается уже магический метод примеси __call(), который, в свою очередь, вызывает псевдо-магический метод агрегатора __access_call, в который Леонид забыл добавить проверку ошибок. Поскольку проверка ошибок отсутствует, ничего не происходит и никакой ошибки мы не получаем, хотя мне лично хотелось бы. Да и сам граф сложноват получился, на мой взгляд, для реализации примесей на 80 строк… Ошибку исправить, конечно, легко.

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

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

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

Я активно пользуюсь тайпхинтингом в PHP для дополнительных проверок. У Леонида не заметил, но это пустяки.

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

Кстати, вариант автора уже работает в проекте, а мой еще нет. Лежит себе на компе без дела…

Из не относящегося к делу, могу отметить, когда на сайте читаешь код, хотелось бы видеть если уж не выделение синтаксиса цветом, то хотя бы, чтобы отступы были нормальные. Код Леонида для анализа пришлось в Zend Studio форматировать J. Приношу свои извинения, если код на сайте не предназначался для анализа посторонними. Меня оправдывает разве что то, что все же он получен из открытых источников.

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

Огромная просьба в комментариях не сравнивать две реализации с точки зрения «плохая/хорошая». Уважайте себя. Говоря о достоинствах и недостатках, воздержитесь от демагогии. Факты, факты и еще раз факты. Троллей, обожающих кричать «УГ» и «КГ/АМ» даже не разобравшись в вопросе, просят пройти на посадку, поезд скоро отправится.

Спасибо за внимание.

Если вам интересно узнать, какой язык в действительности был первым ООП-языком на свете, могут ли Java и C# называться чистыми ООП-языками, а также проникнуться некоторыми другими деталями, приглашаю вас под кат..

Сначала перевод об истории ООП из Википедии:

«Термины «объектно-» и «ориентированный» в современном смысле этих слов появились в MIT в конце 1950 начале 1960 годов. В среде специалистов по искусственному интеллекту термин «объект» мог относиться к идентифицированным элементам (атомы Lisp) со свойствами (атрибутами). Алан Кэй позже писал, что понимание внутреннего устройства Лиспа оказало серьезное влияние на его мышление в 1966 г. Другим ранним примером ООП в MIT был Sketchpad созданный Иваном Сазерлендом в 1960-61. В глоссарии подготовленного в 1963 г. технического отчета, основанного на его диссертации о Sketchpad, Сазерленд определяет понятия «объект» и «экземпляр» с концепцией классов на основе «мастера» или «определения», хотя все эти термины относились к графическому представлению объектов [вкратце, в Sketchpad было основное изображение, на основе которого строились копии. При изменении основного – копии тоже менялись. Прим. пер.].

В ранней MIT-версии ALGOL AED-0 структуры данных («плексы» на диалекте Алгола) напрямую были связаны с процедурами, которые впоследствии были названы сообщениями, методами или функциями-членами.

Объекты, как формализованный концепт появились в программировании в 1960-х в Simula 67, модернизированной версии Simula I, языка программирования, ориентированного на дискретно-событийное моделирование. Авторы Simula – Оле-Йохан Даль и Кристен Нюгорд из Норвежского компьютерного центра в Осло. Simula разрабатывалась под влиянием SIMSCRIPT и предложенной Чарльзом Хоаром концепцией записей-классов. Simula включала в себя понятие классов и экземпляров (или объектов), а также подклассов, виртуальных методов, сопрограмм и дискретно-событийное моделирование как часть собственной парадигмы программирования. В языке использовался автоматический сборщик мусора, который был изобретен ранее для функционального языка Lisp. Simula использовалась тогда преимущественно для физического моделирования. Идеи Simula оказали серьезное влияние на более поздние языки, такие как Smalltalk, варианты Lisp (CLOS), Object Pascal, и  C++.

Язык Smalltalk, который был изобретен в компании Xerox PARC Аланом Кэем (Alan Kay) и некоторыми другими учеными, фактически навязывал использование «объектов» и «сообщений» как базиса для вычислений. Создателей Smalltalk вдохновляли некоторые идеи Simula, но Smalltalk разрабатывался как полностью динамичная система, в которой классы могут создаваться и изменяться динамически, а не только статически как в Simula. Smalltalk и ООП с его помощью были представлены широкой аудитории в журнале Byte magazine в августе 1981.

В 1970-х Smalltalk Кэя сподвиг сообщество Lisp внедрить в язык объектно-ориентированные техники, которые были представлены разработчикам с помощью Lisp машины.
Эксперименты с различными расширениями Lisp в конечном итоге привели к созданию Common Lisp Object System (CLOS, части первого стандартизованного объектно-ориентированного языка, ANSI Common Lisp), который органично включал в себя как функциональное, так и объектно-ориентированное программирование и позволял расширять себя с помощью протокола Meta-object protocol. В 1980 было несколько попыток дизайна архитектур процессоров, которые включали бы в себя аппаратную поддержку работы с объектами в памяти, но все они были безуспешны. В качестве примеров можно привести Intel iAPX 432 и Linn Smart Rekursiv.

Объектно-ориентированное программирование развилось в доминирующую методологию программирования в начале и середине 1990 годов, когда стали широко доступны поддерживающие ее языки программирования, такие как Visual FoxPro 3.0, C++, и Delphi. Доминирование этой системы поддерживалось ростом популярности графических интерфейсов пользователя, которые основывались на техниках ООП. Пример тесной связи между динамической библиотекой GUI и объектно-ориентированного языка программирования можно найти посмотрев на фреймворк Cocoa на Mac OS X, который был написан на Objective-C, объектно-ориентированом расширении к С, основанном на Smalltalk с поддержкой динамических сообщений. Инструментарии ООП повлияли на популярность событийно-ориентированного программирования (хотя, эта концепция не ограничивается одним ООП). Некоторые даже думали, что кажущаяся или реальная связь с графическими интерфейсами – это то, что вынесло ООП на передний план технологий.

В ETH Z?rich, Никлаус Вирт и его коллеги тоже исследовали такие предметы, как абстрация данных и модульное программирование, хотя эти подходы широко использовались и в 60-х и ранее. Modula-2 вышедшая в 1978 включала оба эти подхода, а ее последователь Oberon имел собственный подход к объктно-ориентированности, классам и прочему, непохожий на подход Smalltalk и совсем не похожий на подход C++.

Возможности ООП добавлялись во многие языки того времени, включая Ada, BASIC, Fortran, Pascal и другие. Их добавление в языки, изначально не разрабатывавшиеся для поддержки ООП часто приводило к проблемам с совместимостью и поддержкой кода.

Позднее стали появляться языки, поддерживающие как объектно-ориентированный подход, так и процедурный вроде  Python и  Ruby. Пожалуй, самыми коммерчески успешными объектно-ориентированными языками можно назвать Visual Basic.NET, C# и Java. И .NET и Java демонстрируют превосходство ООП.»

Теперь я бы хотел привести перевод небольшой части статьи «Как начиналось объектно-ориентированное программирование» за авторством Оле-Йохана Даля и Кристена Нюгорда.

«SIMULA I (1962-65) и Simula 67 (1967) – два первых объектно-ориентированных языка программирования. Simula 67 включала в себя большую часть концепций объектно-ориентированного программирования: классы и объекты, подклассы (наследование), виртуальные функции, безопасные ссылки и механизмы, позволяющие внести в программу коллекцию программных структур, описанных общим заголовком класса (префиксные блоки).

Алан Кэй из Xerox PARC использовал Simula как платформу для его разработки Smalltalk (первых версий языка в 1970-х), расширяя объектно-ориентированное программирование с помощью интеграции пользовательского интерфейса и интерактивного исполнения. Бьерн Страусструпп начал разработку C++ (в 1980-х) by привнеся основные концепции Simula в С.»

Теперь небольшое обобщение и заключение.

Как видите, получается, что первым ООП языком была Simula. Но первым «чистым» ООП языком был именно Smalltalk. «Чистым» иногда называют ООП язык, все типы которого являются или могут быть прозрачно представленными классами. В этом смысле Java чистым ООП языком стала только в версии 5, когда появилась возможность Autoboxing. C#, если я правильно понимаю, был чистым ООП языком с самого начала. Предлагаю в комментариях поломать копья на темы вроде «А в C# есть неуправляемые указатели, которые не могут быть представлены объектами», «А вообще чистым ООП языком может считаться только Smalltalk, в котором объектами представлено все, вплоть до блоков самой программы, ну или, в крайнем случае, Ruby» и «Чистый – значит, медленный. Ишь чего удумали, int объектом представлять!»

Некоторое время назад один странный хабраюзер заявил в одном из комментариев, что ООП изобрел Алан Кэй, что в чистом ООП нет наследования, что Java и C# по мнению автора термина «ООП» Алана Кэя ООП языками не являются и что Гослинг с Липпертом имеют… гм… проблемы, поскольку совершенно неверно считают, что изобретенные ими языки являются нормальными объектно-ориентированными.

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

Объектно-ориентированное программирование – парадигма, научный подход к программированию, который разрабатывался не в вакууме, а большой группой ученых. Вклад  Кэя в ООП неоценим, но говорить, что ООП – целиком и полностью его изобретение будет несправедливо по отношению ко многим другим ученым, работавшим как вместе с ним, так и отдельно. Кэй действительно когда-то говорил, “I didn’t like the way Simula I or Simula 67 did inheritance (though I thought Nygaard and Dahl were just tremendous thinkers and designers). So I decided to leave out inheritance as a built-in feature until I understood it better.” Как вы понимаете, монополия на изобретение ООП им не заявлялась.

Говорить, что в ООП нет наследования (и всяких прочих современных штучек) и что те, кто его туда привнес извратили смысл и суть ООП, это все равно, что говорить, что геометрия Лобачевского извратила геометрию, изобретенную Евклидом и ее срочно нужно переименовать в «шарометрию» или «гиперболометрию», чтобы грязные руки неофитов не смели касаться святого. Геометрия Римана – вообще тогда от сатаны, а бозонную струнную теорию нельзя преподавать в университетах потому, что это не то, что описывал Габриэле Венециано и его коллеги.

Если вы не согласны, приглашаю продолжить дискуссию в комментах.

За статьей последует разбор моих собственных ошибок по этой теме, допущенных в одном старом проекте. Я был молод и глуп, но это меня не извиняет.

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

Если вы опытный DBA, наверное, вам стоит пройти мимо, чтобы не расстраиваться.

Но обо всем по порядку. Сначала ОЧЕНЬ сокращенный перевод:

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

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

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

Я не говорю о том, что суррогатные ключи нельзя использовать вообще, я говорю о том, что нельзя злоупотреблять их использованием.

Какие причины могут побудить нас использовать суррогатные ключи?

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

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

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

Согласованность данных. Обычно убедительна. Но только в том случае, если вы действительно скрупулезно следуете плану и весь ваш дизайн тщательно спланирован.

Следование SQL стандарту и принципам дизайна. Очень плохая причина. Она полностью основана на невежестве. Обычно, ей следуют потому, что где-то услышали, как кто-то прочитал в блоге кого-то, кто учится в УНИВЕРСИТЕТЕ, что использование суррогатных ключей – это стандарт в индустрии. Имейте ввиду, что ни современные стандарты SQL, ни сама реляционная теория не содержит даже упоминания о суррогатных ключах.

Возможность легкого изменения. Неясно. Действительно, некоторые СУБД не умеют выполнять ON UPDATE CASCADE или делают это слишком неэффективно (кстати, подумайте об этом как о причине смены СУБД). И в этом случае, данная причина может оказаться весомой. Однако иногда разработчики говорят о том, что ключи [первичные] для записи меняться не должны и должны оставаться одинаковыми на всей протяженности жизненного цикла записи. Имейте ввиду, что это утверждение яйца выеденного не стоит и уж, разумеется, полностью отсутствует в реляционной теории.

Производительность. Обычно плохая причина. Да, действительно, могут возникать ситуации, в которых использование естественных ключей сильно замедляет работу системы по сравнению с суррогатными. Но в 80% случаев за этим утверждением не стоят реальные тесты и подобное утверждение остается безосновательным. Предварительная оптимизация – корень многих бед в дизайне баз данных.

Для баз данных мега-объема результирующий размер таблицы также может иметь значение. Но для этого база должна быть уж очень большой.

Производительность соединений или сортировки также имеет значение на большом количестве данных, в зависимости от типа первичного ключа и числа его компонентов. Однако мой опыт показывает, что когда называют эту причину, за ней очень редко стоят реальные расчеты или замеры производительности. Например, http://www.bricolage.cc использует 14-байтовые числовые первичные ключи для своих таблиц много лет. Однако и в этом случае, после появления пользователя с трехмиллионной записью в истории, когда встал вопрос об изменении первичных ключей ради производительности, эта проблема была решена переписыванием запросов. Было достигнуто примерно 10-кратное увеличение производительности.

Обратите внимание, что проблемы причиняет не использование суррогатных ключей, а злоупотребление ими».

Конец моего ОЧЕНЬ СОКРАЩЕННОГО перевода. Оригинал тут (Primary Keyvil называется): http://it.toolbox.com/home/search.aspx?r=%22Primary+kevill%22&community=1&contentType=5

Если я упустил что-то важное в переводе, пожалуйста, скажите мне об этом. Добавлю.

Теперь немного о том, что я сам думаю. Все же статья показалось мне немного драматизирующей проблему. Мне кажется, что суррогатные ключи выбираются все чаще всего именно из-за того, чтобы избежать проблем с производительностью впоследствии и в последнее время все так к ним привыкли, что они насаждаются на уровне самих СУБД. Например, InnoDB, если вы не создадите первичный ключ, просто создаст его сама. Кстати, в случае с InnoDB выбор первичного ключа имеет серьезные последствия с точки зрения производительности, поскольку по нему производится кластеризация (соответственно, выбор естественного ключа может как улучшить, так и ухудшить ситуацию).

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

Эта статья открыла мне глаза в том плане, что я всегда считал естественным не искать себе особых кандидатов в первичные ключи, а просто создать INT NOT NULL AUTO_INCREMENT PRIMARY KEY поле и сидеть спокойно. Разумеется, я знал о том, что в качестве первичного ключа можно выбрать любой уникальный ключ, но я никогда на этом не акцентировался. Я никогда особо не задумывался о том, что вообще по-настоящему делает данную строку базы данных уникальной и почему это важно. Как выяснилось, зря.

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

Проект представляет собой некоторый закрытый торрент-трекер. Я прошу вас не обращать сейчас внимание на проблемы с нормализацией и всякие другие. Если бы я писал его сейчас, может быть, кое-что я бы сделал по-другому. Давайте сосредоточимся на суррогатных ключах.

Исходный код

CREATE TABLE `log` (
  `log_id` int(10) UNSIGNED NOT NULL AUTO_INCREMENT,
  `user_id` int(10) UNSIGNED NOT NULL,
  `log_ip` varchar(15) NOT NULL,
  `log_error_text` text NOT NULL,
  `log_occured_on` datetime NOT NULL,
  PRIMARY KEY (`log_id`),
  KEY `user_id` (`user_id`),
  KEY `log_occured_on` (`log_occured_on`)
) TYPE=InnoDB  AUTO_INCREMENT=2 ;
 
CREATE TABLE `peer` (
  `peer_id` int(10) UNSIGNED NOT NULL PRIMARY KEY,
  `peer_info_hash` char(20) BINARY NOT NULL,
  `torrent_id` int(10) UNSIGNED NOT NULL,
  `user_id` int(10) UNSIGNED NOT NULL,
  `peer_ip` int(11) NOT NULL DEFAULT '0',
  `peer_port` smallint(5) UNSIGNED NOT NULL DEFAULT '0',
  `peer_update_time` timestamp NOT NULL,
  `peer_expire_time` timestamp NOT NULL DEFAULT '0000-00-00 00:00:00',
  `peer_left` bigint(20) UNSIGNED NOT NULL,
  `peer_uploaded` bigint(20) UNSIGNED NOT NULL,
  `peer_downloaded` bigint(20) UNSIGNED NOT NULL,
  `peer_upload_speed` int(11) UNSIGNED NOT NULL,
  `peer_download_speed` int(11) UNSIGNED NOT NULL,
  UNIQUE KEY hash(`peer_info_hash`,`peer_ip`,`peer_port`),
  KEY `torrent_id` (`torrent_id`),
  KEY `peer_left` (`peer_left`),
  KEY `peer_expire_time` (`peer_expire_time`),
  KEY `peer_update_time` (`peer_update_time`),
  KEY `user_id` (`user_id`)
) TYPE=HEAP;
 
CREATE TABLE `session` (
  `session_id` char(40) NOT NULL,
  `user_id` int(11) UNSIGNED NOT NULL,
  `session_ip` char(15) NOT NULL,
  `session_expire_time` datetime NOT NULL,
  PRIMARY KEY (`session_id`),
  KEY `user_id` (`user_id`)
) TYPE=HEAP;
 
CREATE TABLE `torrent` (
  `torrent_id` int(10) UNSIGNED NOT NULL AUTO_INCREMENT,
  `torrent_info_hash` char(20) BINARY NOT NULL,
  `torrent_downloaded_last_month` int(10) UNSIGNED NOT NULL DEFAULT '0',
  `torrent_downloaded_this_month` int(10) UNSIGNED NOT NULL DEFAULT '0',
  `torrent_file_name` char(200) NOT NULL,
  `torrent_file_path` text NOT NULL,
  `torrent_size` bigint(20) UNSIGNED NOT NULL,
  PRIMARY KEY (`torrent_id`),
  UNIQUE KEY `torrent_info_hash` (`torrent_info_hash`)
) TYPE=InnoDB  AUTO_INCREMENT=57 ;
 
CREATE TABLE `user` (
  `user_id` int(10) UNSIGNED NOT NULL AUTO_INCREMENT,
  `user_serial` char(40) NOT NULL,
  `user_account_status` enum('Active','Suspended') NOT NULL,
  `user_access_levels` text NOT NULL,
  `user_torrent_uid` char(8) BINARY NOT NULL,
  `user_closure_reason` text,
  `user_closure_reason_public` text,
  `user_uploaded_total` bigint(20) UNSIGNED NOT NULL DEFAULT '0',
  `user_uploaded_month` bigint(20) UNSIGNED NOT NULL DEFAULT '0',
  `user_uploaded_week` bigint(20) UNSIGNED NOT NULL DEFAULT '0',
  `user_uploaded_day` bigint(20) UNSIGNED NOT NULL DEFAULT '0',
  `user_downloaded_total` bigint(20) UNSIGNED NOT NULL DEFAULT '0',
  `user_downloaded_month` bigint(20) UNSIGNED NOT NULL DEFAULT '0',
  `user_downloaded_week` bigint(20) UNSIGNED NOT NULL DEFAULT '0',
  `user_downloaded_day` bigint(20) UNSIGNED NOT NULL DEFAULT '0',
  `user_webdownloaded_total` bigint(20) UNSIGNED NOT NULL DEFAULT '0',
  `user_webdownloaded_month` bigint(20) UNSIGNED NOT NULL DEFAULT '0',
  `user_webdownloaded_week` bigint(20) UNSIGNED NOT NULL DEFAULT '0',
  `user_webdownloaded_day` bigint(20) UNSIGNED NOT NULL DEFAULT '0',
  `user_torrentfiles_total` int(10) UNSIGNED NOT NULL DEFAULT '0',
  `user_torrentfiles_month` int(10) UNSIGNED NOT NULL DEFAULT '0',
  `user_torrentfiles_week` int(10) UNSIGNED NOT NULL DEFAULT '0',
  `user_torrentfiles_day` int(10) UNSIGNED NOT NULL DEFAULT '0',
  `user_no_traffic_limits` enum('Y','N') NOT NULL DEFAULT 'N',
  PRIMARY KEY (`user_id`),
  UNIQUE KEY `user_serial` (`user_serial`),
  UNIQUE KEY `user_torrent_uid` (`user_torrent_uid`)
) TYPE=InnoDB  PACK_KEYS=0 AUTO_INCREMENT=3 ;

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

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

Ответ очень простой. Комбинация из ID пользователя и времени возникновения события. И вот тут я неожиданно увидел ситуацию с другой стороны. Практически во всех моих старых проектах поле DATETIME используется для хранения времени в логах. Просто потому, что это удобно. Да, я знал, что оно хранится с точностью до секунды и меня это полностью устраивало. Сейчас, когда я начал искать естественные ключи, мне неожиданно пришло в голову, какие последствия это несет. Торрент-трекер, о котором идет речь, нагружен очень сильно и в течение секунды многое может произойти. Фактически, если в логе с этим чертовым суррогатным ключом окажется несколько событий с одним и тем же временем и они произошли друг за другом очень быстро, я смогу сказать, какое из них произошло первым, а какое последним только ориентируясь по автоинкременту суррогатного ключа. Само поле информации о дате, которое создано именно затем, чтобы сообщать такие вещи, мне ничем не поможет. А точно выяснить интервал между событиями я не смогу вообще.

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

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

Похоже, что мое объяснение получилось сумбурным. Надеюсь, все же, мне удалось донести до вас мою мысль.

Теперь таблица peer. У нее уже есть уникальный ключ, который просто просится на роль первичного. В таблицу peer производятся многие сотни вставок/удалений в секунду и держать там лишний индекс в виде первичного ключа просто накладно. Вот я его и ликвидировал.

Таблица session. По некоторой причине я не полагался на сессии PHP полностью, а частично реализовал свои. В качестве первичного ключа этой таблицы выступает случайное значение. Мало того, что это просто глупо использовать 40-символьные случайные последовательности, так оно тут вообще не очень нужно. Что выступает в качестве естественного ключа для записей в этой таблице? В этом проекте пользователю не позволялось быть залогиненым с нескольких компов одновременно.  Гм. user_id? Все остальное по отношению к данному значению вторично. Я не буду сейчас анализировать, что вытекает из этого простого утверждения. Много чего вплоть до удаления таблицы сессий и реализации другого механизма. Вариантов тут много.

Перейдем к таблице torrent.

Небольшое отступление для того, чтобы вы представляли себе предмет обсуждения. Торрент-трекер, который я разрабатывал, одновременно являлся и первым сидом для файлов, которые раздавались. В таблице torrent хранилась информация о файлах, которые сидировались. Эти файлы лежали в файловой системе сервера, для них создавались соответствующие .torrent файлы по схеме один файл = один торрент, которые и скачивались пользователями. Каждый торрент имеет так называемый info_hash, который его уникальным образом идентифицирует.

Это поле в таблице peer называется peer_info_hash. А в таблице torrent это поле torrent_info_hash. torrent_id там лишний. Совсем. Обратите внимание, что в таблице peer torrent_id тоже есть. Непонятно зачем.

Ну и таблица user. Казалось бы, тут я просто не мог сделать ошибки. Ошибался.

В системе авторизации, например, на rutracker.org, free-torrents.org и прочих используется GET параметр с уникальным для пользователя значением. В таблице это значение user_torrent_uid. Вот спросите меня, кто мешал использовать это значение в качестве естественного ключа в том или ином варианте? Да, оно может измениться. В очень редком случае. Ну и что? Если 8 байт – слишком длинно, можно было взять обычный случайный INT и конвертировать его в текст, как на Flickr делают умные люди. Можно было… Да много чего можно было.

Вот так. Все очевидно, не так ли?