Да, надо тратить столько времени, чтобы построить такое дерево, следить за целостностью при каждом вводе и, таким образом, жертвовать производительностью. В CUBRID и Oracle это займет пару минут написать такой запрос и еще не надо жертвовать производительность. Очень удобно.
Как я Вам говорил на оф. форуме, сначала Вы должны получить сырые данные «0.0e0» с базы в PHP, и затем только делать всю обработку. Тогда Вы и получите, что это не численное значение, а строчное. Если что, пишите. Времени мало осталось. Вы уже отправили рабочую версию?
Как я написал выше, поддержка mysqli синтаксиса нет в планах. В этом пока нет необходимости вообще. Стабильность и производительность нынешнего CUBRID PHP API довольно хорошая, не устпает другим драйверам.
Для того, чтобы работать с ActiveRecord, можно использовать CUBRID PDO драйвер. Все, что Вы хотите, там есть. Вот туториал www.cubrid.org/cubrid_pdo_driver.
Дополнительно есть в планах разработать поддержку CUBRID в PHP ActiveRecord (phpactiverecord.org), а также в Doctrine (doctrine-project.org). Думаю, в этом году уже сделаем.
PDO тоже. А вот mysqli нет, так как там немного другой синтаксис — все через экземпляр. Акцент на главный драйвер, используемый главными приложениями (Wordpress, Joomla, Yii и т.п.). Если смотреть на mysqli, то надо также создать уже отдельные драйвер, который можно будет использовать через экземпляр.
Целью этой статьи было показать как соединяться в PHP с CUBRID. Я не ставил задачи сравнить производительность разных библиотек. Но тем не менее спасибо Вам за комментарий. Я учту Ваше пожелание и в следующей статье обязательно напишу о производительности. Еще раз спасибо.
В «Замечаниях к текущей версии (PDF)» есть весь список изменений в виде содержания (ссылку смотрите выше в конце статьи). Там же есть и более подробное описание каждого изменения. Если есть определенные вопросы, пожалуйста, задавайте. Буду рад ответить!
Спасибо за замечание. Предложение начиналось по другому, а затем изменилось. Получилось: начало от одного предложения, конец от другого. И дело не в знании Русского языка.
В CREATE TABLE не указан ENGINE, так как этот скрипт описывает общую схему таблицы, которая использовалась и в CUBRID, и в MySQL. А так правильно, в случае MySQL также уточнялся и ENGINE.
К сожалению, производителя диска, который был использован тогда, уже не помню. Масштабы результатов могут варьироваться при разных SSD, но направление результатов должно быть одинаковым, так как для обеих систем машины используются одни и те же и обе СУБД не оптимизируются под железо.
Фу, ты! Неправильно понял. Какой нафиг MyISAM! Тест был с InnoDB. MyISAM конфигурации — это все по-умолчанию. А идентичный тест с MyISAM проводили еще в 2009 с CUBRID 8.2.2, но тогда CUBRID отставал. А это результаты 2010 года. А в CUBRID 8.3.0 был изменен алгоритм индексации, что изменило результаты в пользу CUBRID. Если достану данные прошлого теста, опубликую здесь. Думаю Вам будет интересно узнать, какая разница между CUBRID 8.2.2 и 8.3.0.
Для того, чтобы работать с ActiveRecord, можно использовать CUBRID PDO драйвер. Все, что Вы хотите, там есть. Вот туториал www.cubrid.org/cubrid_pdo_driver.
Дополнительно есть в планах разработать поддержку CUBRID в PHP ActiveRecord (phpactiverecord.org), а также в Doctrine (doctrine-project.org). Думаю, в этом году уже сделаем.
Спасибо за комментарий!