Comments 125
А как же транзакции, хранимые процедуры и т.д. и тп.?
Сейчас не планируется. Мы хотим для начала добиться совместимости с MySQL 3.23, в котором всего этого нет :)
Хранимые процедуры — ладно с ними, в embedded БД без них можно обойтись (любителям и профессионалам хранимых процедур — не сердитесь, в общем случае я с вами за одно). А внешние ключи и транзакции imho очень нужны, без них тяжело воспринимать реляционную СУБД как сколько-нибудь полноценную. А область применения найдётся. Небольшие вебприложения под low-load, к примеру, для рабочих групп. Главное чтобы экспорт-импорт был 100%, что называется, «seamlessly» совместим с MySQL 5.1 и PhpMyAdmin 3.3 чтобы люди могли спокойно мигрировать на полноценную MySQL по мере роста потребностей и возможностей.
Между прочим, MyISAM внешние ключи и транзакции не поддерживает, а ведь это очень долго был дефолтный движок в MySQL :)!
А экспорт и импорт конечно сделаем, потому что именно на это и рассчитано — дать возможность человеку поработать без MySQL настолько долго, насколько это возможно, но с возможностью после этого пересесть на MySQL безболезненно.
А экспорт и импорт конечно сделаем, потому что именно на это и рассчитано — дать возможность человеку поработать без MySQL настолько долго, насколько это возможно, но с возможностью после этого пересесть на MySQL безболезненно.
> Между прочим, MyISAM внешние ключи и транзакции не поддерживает
Именно поэтому пока InnoDB-движок в MySQL более-менее не созрел, я пользовался только MS SQLServer. Ниша MyISAM, на сколько я понимаю, mid/high load consumer приложения, прежде всего с большой интенсивностью инсертов и апдейтов, там она себя оправдывает. А в Enterprise (не зависимо два там клиента или десятки тысячь) транзакции необходимы, и в low-load внешними ключами вряд ли есть смысл принебрегать, да простит меня К.О.
Именно поэтому пока InnoDB-движок в MySQL более-менее не созрел, я пользовался только MS SQLServer. Ниша MyISAM, на сколько я понимаю, mid/high load consumer приложения, прежде всего с большой интенсивностью инсертов и апдейтов, там она себя оправдывает. А в Enterprise (не зависимо два там клиента или десятки тысячь) транзакции необходимы, и в low-load внешними ключами вряд ли есть смысл принебрегать, да простит меня К.О.
UFO just landed and posted this here
Уже спрашивали. В общем, в основном для получения опыта и получения представления о том, как работают СУБД. А заодно заставить хостеров добавить MySQL даже для самых дешевых тарифов.
На самых дешёвых тарифах, как правило (по крайней мере из того, с чем я сталкиваюсь), нет не только MySQL, но и PHP (и появляются они с повышением цены вместе, а дальше меняются колличественные характеристики). Иначе я сейчас же бы воспользовался MooSQL. Напишем РСУБД на SSI? :-)
А вот для образовательных целей очень может оказаться полезной вешью. Потомство оценит если Вы будете писать хорошо структурированный и документированный код. Надеюсь оно ООП :-)
А вот для образовательных целей очень может оказаться полезной вешью. Потомство оценит если Вы будете писать хорошо структурированный и документированный код. Надеюсь оно ООП :-)
Я не понял ваш коммент :)
UFO just landed and posted this here
Хотелось совместимости с MySQL, SQLite такой совместимости не даёт :). Плюс к тому, у SQLite есть некоторые проблемы с разницей хранения данных между SQLite 3 и SQLite 2, а здесь можно поставлять библиотеку, которая будет хранить данные точно в том формате, в котором записана база.
А вообще, я писал изначально это для PHP4, на котором SQLite нет :).
А вообще, я писал изначально это для PHP4, на котором SQLite нет :).
Было бы здорово иметь в комплекте конвертер файлов данных из/в sqlite.
Наверняка несложно сделать, особенно, если конвертировать через промежуточный текстовой SQL-дамп.
(Зачем? Ну, к примеру, был проект на хостинге с SQLite, надо его переложить туда, где SQLite по каким-либо причинам отключен)
Наверняка несложно сделать, особенно, если конвертировать через промежуточный текстовой SQL-дамп.
(Зачем? Ну, к примеру, был проект на хостинге с SQLite, надо его переложить туда, где SQLite по каким-либо причинам отключен)
Сколько же вы лет ее писали? о_О
ну как же! он же не на нашем любимом php! /irony
В пост приглашаются умельцы написания парсеров/генераторов парсеров.
bizon?
bison умеет php генерить?
www.gnu.org/software/bison/
RTFM. Bison умеет все. Но его нужно учить.
RTFM. Bison умеет все. Но его нужно учить.
Молодцы, так держать!
Вы выкинули в никуда кучу времени. Поздравляю!
Как по-Вашему, создатели MySQL тоже выкинули вникуда кучу времени, или нет? Чем СУБД на PHP хуже?
UFO just landed and posted this here
Вот смотрите, к примеру, это страница форума на основе MooSQL: datapoliten.ru/misc/fdklab__AA221tda/moosql_test_forum/index.php?act=viewtopic&t=1400. Выборка порядка 20 сообщений из базы в 130 000 меньше, чем за 0.014 сек — это медленно (во время входит не только время исполнения запросов)?
Когда я думал, делать её вообще или нет, я руководствовался тем соображением, что скорее всего в современных СУБД ограничивающим фактором является не процессор, а работа с файловой системой и диском. Процессоры станут быстрее, а вот жесткие диски, особенно по времени произвольного доступа — вряд ли. Да, PHP медленный, но только в сравнении с голым Си. И на нём всё равно можно писать сложные системы, вот только трудозатраты будут меньше в несколько раз.
Когда я думал, делать её вообще или нет, я руководствовался тем соображением, что скорее всего в современных СУБД ограничивающим фактором является не процессор, а работа с файловой системой и диском. Процессоры станут быстрее, а вот жесткие диски, особенно по времени произвольного доступа — вряд ли. Да, PHP медленный, но только в сравнении с голым Си. И на нём всё равно можно писать сложные системы, вот только трудозатраты будут меньше в несколько раз.
Я бы не стал так утверждать. На большинстве реальных серверов, которые мне попадались, операции с файлами производятся быстрее, чем с базой. А временем исполнения самого PHP-скрипта часто можно пренебречь. Поправьте меня, если я неправ.
Мне кажется, это может стать успешным проектом. У меня была подобная идея, только я хотел портировать код SQLite на PHP. Но идея показалась слишком безумной и ненужной.
Мне кажется, это может стать успешным проектом. У меня была подобная идея, только я хотел портировать код SQLite на PHP. Но идея показалась слишком безумной и ненужной.
Нет. Создатели MySql — молодцы, что создали базу, которой успешно пользуется куча людей. Правда, надеюсь, MySql скоро умрет под напором NoSQL баз.
А вот вы выкинули время в никуда. Кто будет пользоваться вашей базой? Где вы видели такие хостинги без MySql? Если хостинг без базы, то сделать все на файлах куда как быстрее и лучше, чем городить 100500 абстракций для поддержки SQL, в которых (абстракциях) еще и багов будет несметное множество.
Разница за хостинг без и с мускулом — копейки. Ваш проект — мертворожденный.
Если у вас есть куча времени и желания, то можно приложить свои усилия в куда как более перспективные направления. Лично я жалею, что в сутках только 24 часа, т.к. идей немерено, а времени их реализовывать мало.
А вот вы выкинули время в никуда. Кто будет пользоваться вашей базой? Где вы видели такие хостинги без MySql? Если хостинг без базы, то сделать все на файлах куда как быстрее и лучше, чем городить 100500 абстракций для поддержки SQL, в которых (абстракциях) еще и багов будет несметное множество.
Разница за хостинг без и с мускулом — копейки. Ваш проект — мертворожденный.
Если у вас есть куча времени и желания, то можно приложить свои усилия в куда как более перспективные направления. Лично я жалею, что в сутках только 24 часа, т.к. идей немерено, а времени их реализовывать мало.
Если хостинг без базы, то сделать все на файлах куда как быстрее и лучше
Обоснуйте, пожалуйста. На данный момент у нас поддержки SQL собственно нет, но вот производительность уже сравнить можете. Сейчас это чисто файловый движок, без SQL абстракций. Тоже не нужно, скажете?
А вот вы выкинули время в никуда. Кто будет пользоваться вашей базой? Где вы видели такие хостинги без MySql?
В основном этот проект ориентирован на Open Source разработчиков, которые хотят добавить как раз тот самый «файловый движок» в свои продукты без необходимости собственно его реализовывать и отлаживать.
сделать все на файлах куда как быстрее и лучше, чем городить 100500 абстракций для поддержки SQL, в которых (абстракциях) еще и багов будет несметное множество.
Про несметное множетсво багов мне тоже не очень понятно. Почему вдруг они должны появиться? Для отлова багов проводится тщательное автоматическое тестирование, тот же SQLite проходит порядка 2 млн. тестов перед каждым релизом, насколько мне известно. А мы будем использовать тесты, написанные для MySQL, чтобы как раз-таки убедиться в отличии расхождений между MySQL и MooSQL :).
Если у вас есть куча времени и желания, то можно приложить свои усилия в куда как более перспективные направления. Лично я жалею, что в сутках только 24 часа, т.к. идей немерено, а времени их реализовывать мало.
Приведите пример, что Вы считаете перспективным направлением? К тому же, я трачу не так уж много времени, и только когда хочу. И у меня тоже много других идей, которые я тоже постепенно воплощаю в жизнь.
Если сейчас нет поддержки SQL, то откуда эта аббревиатура взялась в заголовке?
Я не говорю о производительности. Я говорю о скорости и удобстве разработки.
Баги есть всегда. Это аксиома. Чем больше внешних библиотек используется, тем сложнее эти баги исправлять и отлавливать. Ваша библиотека на данный момент слишком молода, чтобы говорить об отсутствии проблем. Автоматические тесты отнюдь не гарантируют 100%-ую надежность.
Для меня перспективное направление — стартапы. Для вас, если вы хорошо разбираетесь например в базах, таким направлением может быть создание революционной NoSQL базы без всякого там PHP, который для этих целей совершенно не подходит.
Я не говорю о производительности. Я говорю о скорости и удобстве разработки.
Баги есть всегда. Это аксиома. Чем больше внешних библиотек используется, тем сложнее эти баги исправлять и отлавливать. Ваша библиотека на данный момент слишком молода, чтобы говорить об отсутствии проблем. Автоматические тесты отнюдь не гарантируют 100%-ую надежность.
Для меня перспективное направление — стартапы. Для вас, если вы хорошо разбираетесь например в базах, таким направлением может быть создание революционной NoSQL базы без всякого там PHP, который для этих целей совершенно не подходит.
Если сейчас нет поддержки SQL, то откуда эта аббревиатура взялась в заголовке?
На данный момент поддержка SQL активно разрабатывается, и в коде библиотеки есть немало кода, посвященного именно SQL. Тем не менее, оно пока что не документировано и не пригодно к использованию.
Баги есть всегда. Это аксиома. Чем больше внешних библиотек используется, тем сложнее эти баги исправлять и отлавливать. Ваша библиотека на данный момент слишком молода, чтобы говорить об отсутствии проблем. Автоматические тесты отнюдь не гарантируют 100%-ую надежность.
А что в таком случае гарантирует?
Для меня перспективное направление — стартапы. Для вас, если вы хорошо разбираетесь например в базах, таким направлением может быть создание революционной NoSQL базы без всякого там PHP, который для этих целей совершенно не подходит.
Меня лично реляционная модель вполне устраивает, и для абсолютного большинства проектов её производительности и машстабируемости вполне хватает, так что я не стал бы сбрасывать реляционные СУБД со счетов. А с чего Вы решили, что PHP не подходит для разработки СУБД (или веб-сервера, фаерфола, файловой системы и т.д.), мне не очень понятно.
> А что в таком случае гарантирует?
На 100% — ничто. Кроме того, вопрос ведь не только в объемах тестирования, которые вы произвели, но и в банально в доверии к вашему продукту.
Реляционная модель плохо изменяется, плохо приспособлена для задач современного веба (к примеру, древовидные структуры), плохо масштабируема. Под «плохо» понимается «хуже, чем альтернативы». Сравните геморрой, описанный тут: habrahabr.ru/blogs/mysql/76149/, с простотой изменения структур большинства NoSQL баз.
Так что привычные табличные структуры лучше всего хранить в nosql базах, которые и работают быстрее, и программировать под них удобнее. Для древовидных структур существуют графовые базы. А во многих ситуациях обычным key-value хранилищем можно ограничиться.
PHP не подходит не для чего, кроме создания относительно несложных сайтов. Начните писать на других языках, и вопросы сами отпадут. Писать огромное full ajax веб-приложение на PHP — морока страшная. Писать на нем демоны в принципе нереально. Сборка мусора появилась совсем недавно и ее надежность и производительность под оооочень большим вопросом. Кроме того, стандартная библиотека PHP провоцирует программиста на ошибки. Все это жевано-пережевано кучу раз. Хотя, лично мне не нравится разрабатывать на нем и обычные сайты, но это уже другая тема.
У PHP, безусловно, есть достоинства. Но недостатков настолько много, что закрывать на них глаза — просто глупо.
И, да, то, что 100000000 кодеров по всему миру использует PHP и MySQL для меня ничего не значит. Мнение кодеров (именно кодеров, а не толковых программистов) вообще ничего не должно значить.
Разрабатывать можно на чем угодно. Но при этом надо видеть и плюсы, и минусы своего выбора. В противном случае это — ограниченность.
Предлагаю не продолжать тему PHP тут, т.к. лично мне это просто не интересно. Если мой коммент заставит кого-то задуматься — отлично. Если он вызывает только мысли «remal — еритик, а PHP — великий язык», то смело ставьте мне минус и идите дальше. Мне пофиг на карму, но интересны интересные обсуждения. В этом топик готов поговорить на тему баз.
На 100% — ничто. Кроме того, вопрос ведь не только в объемах тестирования, которые вы произвели, но и в банально в доверии к вашему продукту.
Реляционная модель плохо изменяется, плохо приспособлена для задач современного веба (к примеру, древовидные структуры), плохо масштабируема. Под «плохо» понимается «хуже, чем альтернативы». Сравните геморрой, описанный тут: habrahabr.ru/blogs/mysql/76149/, с простотой изменения структур большинства NoSQL баз.
Так что привычные табличные структуры лучше всего хранить в nosql базах, которые и работают быстрее, и программировать под них удобнее. Для древовидных структур существуют графовые базы. А во многих ситуациях обычным key-value хранилищем можно ограничиться.
PHP не подходит не для чего, кроме создания относительно несложных сайтов. Начните писать на других языках, и вопросы сами отпадут. Писать огромное full ajax веб-приложение на PHP — морока страшная. Писать на нем демоны в принципе нереально. Сборка мусора появилась совсем недавно и ее надежность и производительность под оооочень большим вопросом. Кроме того, стандартная библиотека PHP провоцирует программиста на ошибки. Все это жевано-пережевано кучу раз. Хотя, лично мне не нравится разрабатывать на нем и обычные сайты, но это уже другая тема.
У PHP, безусловно, есть достоинства. Но недостатков настолько много, что закрывать на них глаза — просто глупо.
И, да, то, что 100000000 кодеров по всему миру использует PHP и MySQL для меня ничего не значит. Мнение кодеров (именно кодеров, а не толковых программистов) вообще ничего не должно значить.
Разрабатывать можно на чем угодно. Но при этом надо видеть и плюсы, и минусы своего выбора. В противном случае это — ограниченность.
Предлагаю не продолжать тему PHP тут, т.к. лично мне это просто не интересно. Если мой коммент заставит кого-то задуматься — отлично. Если он вызывает только мысли «remal — еритик, а PHP — великий язык», то смело ставьте мне минус и идите дальше. Мне пофиг на карму, но интересны интересные обсуждения. В этом топик готов поговорить на тему баз.
Кстати, с вводом поддержки SQL производительность, по планам, не должна ощутимо ухудшиться. Баги — ну будем править баги, куда денемся. А сообщество, надеюсь, поддержит.
Всем?
а почему в названии sql? какой стандарт поддерживается?
Тем, что на PHP. Нельзя будет использовать в неPHP проектах.
Просмотр телевизора — трата времени впустую. Программирование — нет. :)
пэздец :-)
UFO just landed and posted this here
Интересно посмотреть как оно изнутри работает. Полезно в плане изучения того как работает БД и хранит все. Особенно интересно удаление записей. Как индекс будет при этом себя вести.
Исходники открыты, смотрите :). При удалении записей в файле с данными просто остаются пустые места, а индекс действительно частично и по довольно сложному алгоритму перестраивается, но для Б-дерева используется «упрощенная» система, которая не осуществляет полной перестройки Б-дерева ценой потери гарантии 50% заполненности каждого узла. Удаление из индексов очень тщательно мной тестировалось, причём код самих тестов в проекте на Google Code тоже есть.
Вы меня заинтриговали )) В свое время создавал аналог БД правда под одну задачу: решение анаграмм. Индекс + орфографический словарь в бинарном файле. Решение анаграммы составлял сотые-тысячные доли секунды. Потом усложнил и мне захотелось узнать давно мучавший меня вопрос. Сколько слов можно составить из слова «синхрофазатрон». Оказалось более 200 ;) С тех пор интересных задач и не попадалось (( Правда и вышеописанную я сам для себя придумал.
я когда-то (лет 5 назад) такой-же велосипед на перле изобретал… freshmeat.net/projects/lkbindb
Оно до сих пор пашет в одном из моиих (заброшеных) проектов. все хранилось в двоичных файлах (что «условно» несвойственно перлу).
Если интересно — можете глянуть код. Ой наверно старшный он тогда был :-)
Оно до сих пор пашет в одном из моиих (заброшеных) проектов. все хранилось в двоичных файлах (что «условно» несвойственно перлу).
Если интересно — можете глянуть код. Ой наверно старшный он тогда был :-)
Шикарная картинка
Насколько хорошо документирован проект? И насколько стабилен? И что, например, с INSERT DELAYED — будет работать хоть в каком-то виде? А GROUP_CONCAT?
SQL нету сейчас! Не будет INSERT DELAYED работать сейчас :). Но планируется те директивы, которые ни на что не влияют (тот же DELAYED) просто игнорировать.
Туплю наверное, а какой же интерфейс к БД предполагается?
Умеет MooSQL не очень много — на данный момент доступен лишь API самой YNDb, который описан на этой вики-странице: code.google.com/p/moosql/wiki/HOWTO .
Чертовы фанатики :D
>MySQL-совместимую СУБД на чистом PHP на случай, если в доме закончился обычный MySQL.
>под рукой нет MySQL (по разным причинам, например хостер не позволяет),
вы напишите php-совместимый интерпретатор… на случай, если хостер не позволяет php…
>под рукой нет MySQL (по разным причинам, например хостер не позволяет),
вы напишите php-совместимый интерпретатор… на случай, если хостер не позволяет php…
Имхо, подобные вещи — шаг назад.
И это я пишу не потому что не понимаю вас, а потому что сам делал кучу велосипедов, и СУБД и ОР-маппер и HTTP-сервер, и еще много всяких «полезных штук».
И наконец то дорос до того, что пользуюсь как и все тем, что уже давно сделано :))
В любом случае, удачи вам… :)
И это я пишу не потому что не понимаю вас, а потому что сам делал кучу велосипедов, и СУБД и ОР-маппер и HTTP-сервер, и еще много всяких «полезных штук».
И наконец то дорос до того, что пользуюсь как и все тем, что уже давно сделано :))
В любом случае, удачи вам… :)
Скоро будем PHP'ом щи хлебать!
Поразительное по качеству извращение, одобряю! :)
как бе… и?
напишите сравнение вашей коровячей субд и SQLite?
напишите сравнение вашей коровячей субд и SQLite?
молодцы ребята так держать!
Не обсуждая всю абсурдность идеи. Глянул на код btree_gen.php. Это позор.
Тоже глянул. Половину можно в community.livejournal.com/code_wtf/ постить. Из запомнившегося: метод delete(), сразу после if($ISLEAF) идет $N--. А где изначально присваивается значение этой переменной?
В начале файла реализации Б-дерева честно предупреждается, что это самая сложная часть СУБД и требует хорошей теоретической подготовки для того, чтобы понять код, который там написан. В основном он является портом с примера реализации Б-дерева по этому адресу: www.bluerwhite.org/btree/ (причём с исправлением ошибок в коде примеров :)). Метод delete() «сочинил» я сам, причём я реализовал не полную версию алгоритма удаления из Б-дерева, но зато ту, что есть, постарался очень тщательно прокомментировать.
Не вижу здесь позора, поскольку я не обязан приводить описание непосредственно схемы работы Б-дерева прямо в коде :).
Не вижу здесь позора, поскольку я не обязан приводить описание непосредственно схемы работы Б-дерева прямо в коде :).
UFO just landed and posted this here
B-tree изучают студенты в ВУЗе. Я писал не про алгоритм, который знать весьма полезно, а про качество реализации и код. Вместо того, чтобы писать километровые комментарии, лучше бы отрефакторили код.
Я так и не понял, что в моём коде Вам конкретно не нравится.
Это плохо, что не понимаете.
Вообще говоря, ничего, не нравится.
Ужасный coding style, naming convention.
Есть слово класс. Но это не ООП. Функция обработки ошибок в процедурном стиле.
Debug трейс вместе с форматированием внедер прямо в код, что вносит еще большую путаницу.
Куча вложенных if, циклов. Наверняка можно отрефакторить.
Слишком длинные методы.
Слишком большое кол-во входных параметров у методов.
Не уверен, что этот код пройдет E_ALL | E_STRICT.
Вообще говоря, ничего, не нравится.
Ужасный coding style, naming convention.
Есть слово класс. Но это не ООП. Функция обработки ошибок в процедурном стиле.
Debug трейс вместе с форматированием внедер прямо в код, что вносит еще большую путаницу.
Куча вложенных if, циклов. Наверняка можно отрефакторить.
Слишком длинные методы.
Слишком большое кол-во входных параметров у методов.
Не уверен, что этот код пройдет E_ALL | E_STRICT.
Функции для обработки ошибок в процедурном стиле только в файле с Б-деревом, насколько я помню (не переписал их ещё на использование исключений, не спорю).
Где Вы предлагаете его держать?
Возможно, их можно сделать проще, но не сильно, там именно сама логика сложная.
По-моему, там от силы 5-6 параметров, причём первые 2 всегда одинаковы (это сделано для того, чтобы один и тот же instance класса можно было использовать для разных файлов с Б-деревом, или же для разных Б-деревьев внутри одного и того же файла), все из которых необходимы и необходимость наличия этих параметров определяется сутью самого метода.
С тем, что код delete() длинный я соглашусь, а все остальные методы, ИМХО, достаточно короткие.
Может, и не пройдёт. Это показатель качества кода?
Debug трейс вместе с форматированием внедер прямо в код, что вносит еще большую путаницу.
Где Вы предлагаете его держать?
Куча вложенных if, циклов. Наверняка можно отрефакторить.
Возможно, их можно сделать проще, но не сильно, там именно сама логика сложная.
Слишком большое кол-во входных параметров у методов.
По-моему, там от силы 5-6 параметров, причём первые 2 всегда одинаковы (это сделано для того, чтобы один и тот же instance класса можно было использовать для разных файлов с Б-деревом, или же для разных Б-деревьев внутри одного и того же файла), все из которых необходимы и необходимость наличия этих параметров определяется сутью самого метода.
Слишком длинные методы.
С тем, что код delete() длинный я соглашусь, а все остальные методы, ИМХО, достаточно короткие.
Не уверен, что этот код пройдет E_ALL | E_STRICT.
Может, и не пройдёт. Это показатель качества кода?
Ну и другие файлы не лучше?
client.php.
У класса с модификатором final есть protected методы.
MooResource то же самое.
Зачем в состояние класса MooResource добавлен sql? Он нигде не фигурирует кроме конструктора.
if (isset($this->parser)) — дурацкая проверка, так как параметр обязателен.
DataInterface.php
О! Знакомый set_error, см. пред. пост.
Это что такое: !!fopen_cached ??
метод getTableStructure НЕ может возвращать false, он возвращает structure. Если структуры нету — это null или exception, если она обязательна.
По такому качеству кода далее смотреть я не стал.
client.php.
У класса с модификатором final есть protected методы.
MooResource то же самое.
Зачем в состояние класса MooResource добавлен sql? Он нигде не фигурирует кроме конструктора.
if (isset($this->parser)) — дурацкая проверка, так как параметр обязателен.
DataInterface.php
О! Знакомый set_error, см. пред. пост.
Это что такое: !!fopen_cached ??
метод getTableStructure НЕ может возвращать false, он возвращает structure. Если структуры нету — это null или exception, если она обязательна.
По такому качеству кода далее смотреть я не стал.
!!fopen_cached() — это более короткий эквивалент (bool)fopen_cached(...)
Возможно, Вы и правы.
Это файлы Паши, может быть он Вам и ответит :).
А вообще, на данный момент самая важная часть СУБД лежит в core/, в том числе и Db.php
Этот метод больше не используется в DataInterface (как и почти везде в core/) и оставлен «на всякий случай», если я вдруг где-то забыл заменить вызовы set_error на throw new Exception(...).
метод getTableStructure НЕ может возвращать false, он возвращает structure. Если структуры нету — это null или exception, если она обязательна.
Возможно, Вы и правы.
client.php.
Это файлы Паши, может быть он Вам и ответит :).
А вообще, на данный момент самая важная часть СУБД лежит в core/, в том числе и Db.php
О! Знакомый set_error, см. пред. пост.
Этот метод больше не используется в DataInterface (как и почти везде в core/) и оставлен «на всякий случай», если я вдруг где-то забыл заменить вызовы set_error на throw new Exception(...).
Ну вот открываем Index.php. И что?
Все то же самое можно сказать и об этом файле.
function delete_index($fp, $fpi, $data, $fields, $index, $row_start) — это не метод, это процедура.
Кстати, когда я писал на php, я считал одним из самых важных правил тот факт, что код должен нормально выполняться при: E_ALL | E_STRICT. Это гарантирует защиту хотя бы от глупых ошибок.
Все то же самое можно сказать и об этом файле.
function delete_index($fp, $fpi, $data, $fields, $index, $row_start) — это не метод, это процедура.
Кстати, когда я писал на php, я считал одним из самых важных правил тот факт, что код должен нормально выполняться при: E_ALL | E_STRICT. Это гарантирует защиту хотя бы от глупых ошибок.
Спасибо за то, что ткнули носом в качество кода. Любая критика уместна.
Я, все же, надеюсь, что мы не на экзамене, и можем постепенно улучшать и качество кода и функционал. Шероховатости будут разглажены, баги исправлены, круглое перекачено, а квадратное перенесено.
Я, все же, надеюсь, что мы не на экзамене, и можем постепенно улучшать и качество кода и функционал. Шероховатости будут разглажены, баги исправлены, круглое перекачено, а квадратное перенесено.
Как бы там ни было — для автора это, определенно, level up. А нужно ли это кому-то еще — покажет время. Иногда, самые неожиданные идеи находят свои ниши. В любом случае, удачи!
Посмотрите, такие решения уже есть. Везде пришлось отойти от стандартного SQL по элементарной причине — скорость удручает.
Я в курсе, что есть решения на PHP, которые поддерживают SQL (и делают это довольно плохо, кстати :)), но я не видел ни одной СУБД с поддержкой индексов, а значит их скорость будет сильно падать не только из-за неграмотной работы с SQL, но и из-за необходимости полного просмотра таблицы для любого запроса. Причём найти адекватные парсеры SQL или же «вычленить» SQL-часть из уже имеющихся проектов (вроде FFQL) не представляется возможным и разумным. Мы хотим использовать достаточно простой, и в тоже время гарантирующий высокую производительность, подход для работы с SQL, о котором я могу Вам рассказать подробнее в личке / скайпе / где-нибудь ещё
Не слушайте их.
Ругать PHP модно, ибо есть домохозяечные языки вроде Ruby (сейчас заминусуют).
txtSQL видели, кстати? Может пригодится.
За проект — респект вам.
Напишу на досуге драйвер для своего фреймворка под MooSQL.
Просто для расширения спектра решений для разных применений =)
Ругать PHP модно, ибо есть домохозяечные языки вроде Ruby (сейчас заминусуют).
txtSQL видели, кстати? Может пригодится.
За проект — респект вам.
Напишу на досуге драйвер для своего фреймворка под MooSQL.
Просто для расширения спектра решений для разных применений =)
Видел TxtSQL, но в нем SQL поддержки нет, а блокировки сделаны таким образом, что они могут терять данные ( flock() после fopen() в режиме 'w'… ). Ну и индексы не поддерживает. Помимо того, что их сайт www.txtsql.com/ недоступен :)).
Кстати, если будете делать драйвер, не забудьте учесть, что SQL пока что у нас тоже нет :).
Кстати, если будете делать драйвер, не забудьте учесть, что SQL пока что у нас тоже нет :).
Не скажете кого «их» не слушать? Я программирую на PHP много лет, ещё PHP3 застал.
Спасибо! Послежу за проектом.
подойдет для автоматического тестирования mysql запросов
А через hiphop пропускать пробовали?
Сами собой напрашиваются два вопроса:
1. Нахуя;
2. НАХУЯ?!
Это похапе головного мозга, товарищи.
1. Нахуя;
2. НАХУЯ?!
Это похапе головного мозга, товарищи.
Спасибо за Ваше ценное мнение. По делу есть чо?
на самом деле, взглянув на большую часть, процентов так в 99, разработок в инете можно сказать — «НАХ*Я».
Ребята развиваются, а как в пхп это еще можно без проектов подобного рода.
единственное что конечно вопрос то friday довольно адекватен, но бог в помощь. буду почитывать, может что получится интересное.
правда конечно это еще стоит поискать хостинг без мускула… ну если уж очень бюджетный.
Ребята развиваются, а как в пхп это еще можно без проектов подобного рода.
единственное что конечно вопрос то friday довольно адекватен, но бог в помощь. буду почитывать, может что получится интересное.
правда конечно это еще стоит поискать хостинг без мускула… ну если уж очень бюджетный.
Скоро мы увидим NoNoNoSQL. Если вы делаете маломальски хороший проект, врядли будет проблемой купить хостинг с мускулом, а заниматься этой ерундой — бред, имхо!
Спасение для тех кто размещает cms на дешевых хостингах, теперь хостинг может быть ещё дешевле, без Mysql =)
Спасибо за статью.
Прочитал с удовольствием.
С нетерпением жду DBD::MooSQL
Прочитал с удовольствием.
С нетерпением жду DBD::MooSQL
это извращение
Приходите на DEVCONF 2010 с докладом…
Кроме автором MySQL и Postgres — мы планируем собрать все noSQL DB
devconf.ru/offers
Кроме автором MySQL и Postgres — мы планируем собрать все noSQL DB
devconf.ru/offers
Такая ситуация интересная произошла, намедни наткнулся на статью, прочитал с удовольствием, улыбнулся, подумал про себя: «ведь сейчас везде есть MySQL, не проще ли раздобыть хостинг с мускулом, либо установить его на сервере». По прошествию нескольких дней меня попросили написать 1 штуку, нужно использовать БД, а мускула нет на сервере и установить — гемор очень большой (не будем вдаваться в подробности). Бегом полетел искать эту статью, на этот раз добавил в favorites :)). Автору большое спасибо!!!
Автору-разработчику благодарность за развитие такого проекта.
Немного напрягают возгласы типа: "-а нах оно надо! -везде есть мускуль! -а чем SQLite не устроил" и тп и тд. Слова избалованных веб разработчиков… НО! ведь применение данного инструмента не ограничено рамками веб проектов! Очень кстати будет использование в различных embedded системах, устройствах и тп (примеров много).
Для своего проекта (live система узко заточенного linux) в свое время долго искал mysql совместимый легковесный встраиваемый движок БД. Возможно медленный, со слабым функционалом, но легкий и совместимый с mysql. Кроме sqlite ничего не нашел. Вроде как все почти устраивает, однако нет совместимости с mysql ;(
С удовольствием буду следить за развитием проекта ;)
Немного напрягают возгласы типа: "-а нах оно надо! -везде есть мускуль! -а чем SQLite не устроил" и тп и тд. Слова избалованных веб разработчиков… НО! ведь применение данного инструмента не ограничено рамками веб проектов! Очень кстати будет использование в различных embedded системах, устройствах и тп (примеров много).
Для своего проекта (live система узко заточенного linux) в свое время долго искал mysql совместимый легковесный встраиваемый движок БД. Возможно медленный, со слабым функционалом, но легкий и совместимый с mysql. Кроме sqlite ничего не нашел. Вроде как все почти устраивает, однако нет совместимости с mysql ;(
С удовольствием буду следить за развитием проекта ;)
Sign up to leave a comment.
СУБД на PHP — реально! Представляем MooSQL!