Форум dkLab и Denwer

Юрий Насретдинов

У меня еще очень давно родилась идея написать на PHP базу данных так,чтобы она поддерживала язык запросов SQL, и могла быть заменителем базы MySQL на хостинге. Тогда я решил взять за основу существующий движок plain text базы и к нему написать парсер SQL.

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

Сейчас я решил опять заняться этим вопросом, но решил, что и "ядро" базы тоже будет написано мной, причем с поддержкой индексов. Сейчас я написал некоторую часть ядра, и у меня на данный момент поддерживается создание таблиц с auto_increment полями (такое поле возможно только одно и оно автоматически становится primary key) и числовыми unique key индексами.

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

Вопрос номер 2: интересно ли будет Вам использовать подобную базу данных в своих проектах?

База данных уже сейчас держит индексы, поэтому выборка по primary key или unique key даже из базы в 100 000 записей занимает порядка 0.04 сек при произвольном доступе и 0.005 сек, если данный кусок успел попасть в кэш.

Rumata

получится SmartyDB :)

WingedFox

Юрий Насретдинов
Идея очень симпатичная. Сейчас у меня загрузка очень большая, но чем смогу -- помогу.

Юрий Насретдинов

Rumata wrote:

получится SmartyDB :)

SmartyDB -- это разве не просто «морда» к базе данных вроде MySQL?

WingedFox
Спасибо :). Когда ядро будет хоть в какой-то степени готово, я его выложу сюда (пока что у него уж очень серьёзные ограничения -- разрешено не более одного числового unique поля, select из базы возможен только с одним условием в where, и т.д.).

WingedFox

Юрий Насретдинов
SVN нужон?

Юрий Насретдинов

WingedFox
Спасибо за предложение :). Давай

Rumata

Smarty - компилятор шаблонов, который преобразует набор инструкций, написанных на некотором псевдоязыке, в нормальные конструкции рнр
в данном случае я обыграл это определение

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

А вообще идея красивая.

Юрий Насретдинов

Rumata wrote:

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

Неразумно, согласен...

Rumata wrote:

SmartyDB - компилятор запросов SQL в инструкции работы с файлами.

Можно немного подробнее про него? Единственное вразумительное, что я смог найти по поводу SmartyDB -- doc.quickdev.org/qddoc/HTMLSmartyConverter/SmartyDB/SmartyDB.html, это то?

WingedFox

Ну, если изначально добавить "шаблонизацию" запросов, то разобрать запрос регами надо будет только один раз =)

Rumata

Юрий Насретдинов wrote:

по поводу SmartyDB

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

Юрий Насретдинов

Rumata
Ясно :). А я пытался найти её...

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

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

ff-0.2c.zip

Description:

Download

Filename:

ff-0.2c.zip

Filesize:

16.63 KB

Downloaded:

773 Time(s)

Юрий Насретдинов

М

Ветка выделена в отдельную тему «Оффтоп»,
расположенную в форуме Разное :: PHP (27 Декабря 2007, 23:26).

Юрий Насретдинов

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

Поэтому я и подчёркиваю всё время, что база данных с поддержкой индексов :). Причём PRIMARY INDEX, он же по совместительству AUTO INCREMENT поле, сделан по очень простой схеме -- просто в файлик table.pri в позиции 4*id записывается адрес начала записи в основном файле с данными table.dat, которая соответствует указанному id. Для PRIMARY KEY время доступа получается O(1). А для UNIQUE KEY используется бинарное дерево (пока что без балансировки), что даёт время O(log N) в случае, если поступающие данные достаточно случайны. Самый плохой случай будет, если поступающие данные идут, скажем, в порядке возрастания значений -- в таком случае время доступа будет O(N), что, в общем-то, не сильно отличается от просмотра всей таблицы целиком :).

Валенок

Юрий Насретдинов ага, спасибо что разъяснили..

Юрий Насретдинов

Итак, попробую описать текущую функциональность:

создание таблицы (без проверки структуры) ( YNDb::create(...) ).
В таблице обязательно должно присутствовать строго одно auto_increment поле, чтобы работал PRIMARY индекс. В противном случае возможны тормоза и глюки.
Также опционально доступен один INDEX и один UNIQUE.
Все индексированные поля поддерживают только тип INT.
вставка в таблицу ( YNDb::insert(...) ), с автоматическим проставлением auto_increment значений и заполнением индексов. ВНИМАНИЕ! При нехватке места на диске, или подобных обстоятельствах, возможна порча структуры базы данных без возможности восстановления! Также возможно внесение неправильных записей в базу, что, впрочем, не должно приводить к полной неработоспособности базы (невозможно будет лишь далее добавлять данные и будет некорректно читаться последняя «битая» запись).
выборка из базы ( YNDb::select(...) ) : произвольные столбцы (в том числе и "*"), произвольные значения LIMIT (не меньше нуля), сортировка строго по одному полю и строго одно WHERE условие (>, <, =, IN).
Для WHERE условий применяется оптимизация с использованием индексов в следующих случаях (в скобках указаны операторы, для которых оптимизация прописана):

PRIMARY KEY -- (>, =, IN)
INDEX -- (=)
UNIQUE -- (=).

По сути, это самый-самый минимум для базы (и даже меньше, должен признать), но при желании даже такую базу можно использовать. По поводу INDEX и UNIQUE -- индексы хорошо работают в случае, когда поступающие данные достаточно случайны! В противном случае (в случае упорядоченного поступления данных) эффективность индексов может значительно уменьшиться. Пока что средств вроде REPAIR TABLE нету, поэтому базу данных стоит применять только в случае, если у Вас на сервере нет перебоев с питанием и достаточно места на жёстком диске.

Посмотреть пример работы можно, запустив script/test.php: происходит автоматическое создание таблицы, вставка данных туда и выборка из таблицы.

db.rar

Description:

папка .data -- папка с данными для базы
папка script -- скрипты, db.php -- сам класс базы, test.php -- тестирование базы

P.S. База требует PHP5, но от этого требования можно избавиться, удалив везде private и public, а также добавив пару var для свойс

Download

Filename:

db.rar

Filesize:

4.74 KB

Downloaded:

729 Time(s)

Юрий Насретдинов

Да, пожалуй, базе все-таки до минимума не хватает операций update и удаления записей :).

Юрий Насретдинов

Добавил простейшую реализацию DELETE (и в таблице и в индексе просто остаются «дыры», которые при обходе пропускаются). Также описан синтаксис создания таблицы, теперь есть проверка структуры. На очереди операция UPDATE. После этого я буду думать над расширением возможностей SELECT :).

Проект доступен через SVN: svn.debugger.ru/repos/YNDb/trunk . За выданный SVN благодарю WingedFox :).

P.S. Как-то очень тихо и незаметно проект перевалил за 1000 строчек кода. При этом db.php весит 26 Кб :). Сама идея базы навеяна BerkleyDB, если я не ошибаюсь, в этой базе 100000 строк кода и нет поддержки SQL :).

WingedFox

Юрий Насретдинов
Если есть какие задачи, описывай их тут. Сам я копаться в коде врядли буду, но что-то конкретное сделать могу. 8*)

Юрий Насретдинов

Для начала реализовать обработку запросов INSERT и CREATE TABLE на уровне MySQL 3 версии (3.23 по-моему). Все,что не поддерживается на уровне базы данных, нужно обрабатывать корректно (например, попытку добавления составного индекса нужно считать ошибкой, а, скажем, ключевое слово DELAYED для INSERT запросов, можно молча пропускать, и не считать ошибкой). Причем желательно такие места писать так, чтобы, когда соответствующая функциональность непосредственно в самом ядре базы появится, можно было легко модифицировать код обработки SQL запроса, чтобы он использовал встроенные средства базы.

Юрий Насретдинов

И еще одна важная вещь, которую я забыл: обязательно (!) необходимо правильно обрабатывать строки: например 'ля-ля\' ля' должно рассматриваться именно как ля-ля' ля, но не как ля-ля\. Желательно при этом обойтись без посимвольного разбора (я думаю, можно использовать что-то вроде fgetcsv для этих целей).

[S] · Guest Карма: 386 поощрить/наказать

Ответ на письмо Ю.Н. (Ваша почта сваливается с ошибкой mail delivery failed). Ответ № 1.

Проект называется, если мне изменяет память, FFQL. s.cmsdev.ru/articles/8/
1. Уже нет. Проект умер давно. Это проект работал только с простыми запросам, с более сложными он не справляется. (Т.е. Врядли думаю что это станет заменой).
3. Желания - нет.
2. Я не против, используй.

Прочитал темку.
> Вопрос номер 2:
В своих проектах я бы точно не стал это использовать, т.к. по моим наблюдениям, PHP "нормально" работает c файлами менее 1М. При больших объемах, как вы там хотите, 100 000 записей - это... это я не знаю что будет тогда. В UNMS (s.cmsdev.ru) я использовал другой принцип - один файл - одна запись. Там есть некое подобие индексирования, т.е. если представляете структуру таблицы типа comments. Выбрать из такой "таблицы" все комментарии к определенной новости можно было действительно быстро (без просмотра всей "таблицы"). Но там реализовано по другому все, сделано как класс DB, причем каждый класс DB, для разного типа "таблиц", если интересно, то s.cmsdev.ru - Umbrella NMS. Но такой подход (одна запись - один файл) - это замена шила на мыло, т.к. PHP может создавать несколько файлов можно только при выключенном safe_mode. Изначально все проекты были расчитаны на "бедных буратин" (игровые кланы и т.п. коммунити), у которых нет денег на платный хостинг, и с расчетом на бесплатный с поддержкой PHP. А у большинства хостеров он включен. Даже не знаю что проще: найти PHP хостинг с выключенным safe_mode, или бесплатный хоситнг с MySQL. (наверное, второе). Другая причина - это то что хостинг сейчас очень дешевый, любой школьник может себе позволить. Т.к. что уже (теперь), я считаю, что такой проект - не найдет практического применения.

Мне какой-то то-ли немец, то-ли голландец тоже писал по этому поводу, что, дескать, он "почти" понимает как "мое творение" работает и хочет его "доработать". За смысл не ручаюсь, т.к. он прислал письмо на русском в машинном переводе =)
Если вы заинтересованы в сотруднечестве с ним, то попытаюсь найти письмо

Удачи.

Ответ номер 2.
Зовут того кента "Iain Staffell". Письмо не удалось найти, имя вспомнилось благодаря поднятым записям в блоге. также известно что у него есть аккаунт на sourceforge как-то так: istaffel, не помню...

P.S. Больше я в эту тему не вернусь.

Юрий Насретдинов

Ну, в общем, смотрите как знаете. Мне понравилась идея обработки SQL запросов -- это, по-моему, единственная реализация с поддержкой JOIN'ов хоть в какой-то мере. То, что Ваш движок для работы с файлами никуда не годится (не масштабируется совершенно :) ), это несущественно. Раз люди пишут целые базы данных вроде BerkleyDB, в которых SQL нету, говорит о сложности реализации быстрой и масштабируемой базы :).

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

Юрий Насретдинов

Выложил описание API для тех методов, для которых синтаксис уже вряд ли будет меняться.

deMone

Quote:

Добавил простейшую реализацию DELETE (и в таблице и в индексе просто остаются «дыры», которые при обходе пропускаются).

Скоро нужно будет делать VACUUM :)

deMone

Попутно, вдруг поможет чем: sourceforge.net/projects/osqlp/

Юрий Насретдинов

Написал частичную реализацию UPDATE (строки можно заменять на менее длинные, или такие же по длине, нельзя обновлять значения INDEX полей (это не касается UNIQUE)). В SVN эта версия ещё не выложена (я выложу, как только появится более-менее адекватная реализация UPDATE для INDEX полей).

Чтобы продемонстрировать, как работает моя база сейчас, я хочу показать свой же форум, в котором большАя часть переписана с использования SQL на нативный интерфейс базы (а именно: ЧПУ, листинг форумов, просмотр списков тем для каждого форума, просмотр самой темы, создание новой темы, добавление своего сообщения).

При этом, я в него экспортировал базу сообщений forum.dklab.ru (ноябрь 2007 года; база не содержит ничего, кроме сообщений и списка форумов -- всё это итак лежит в открытом доступе), и вы можете сами посмотреть, как оно работает с таким объемом базы. Хочу отметить следующее: база «тормозит» при большом количестве повторяющихся значений для INDEX полей, но в целом вы увидите, что выигрыш по сравнению с полным просмотром базы (60 Мб!!) очень большой.

Скачать саму базу можно отсюда: f.dolphin-php.org/files/yuac_forum.rar (15.39 Мб)
Модифицированный движок форума: f.dolphin-php.org/files/yuac_forum_engine.rar (115 Кб)

После того, как вы распакуете движок форума, откройте config.php и укажите вместо "K:\\YNDb\\yuac_forum" папку, в которую вы распаковали базу данных. После этого можете запускать форум: вы должны увидеть список форумов, как на forum.dklab.ru, иметь возможность просматривать форумы и темы, а также постить новые сообщения и темы (правда, всё от пользователя Guest, к сожалению).

Форумы с большим количеством тем (измеряемое тысячами) и темы с большим количеством сообщений работают довольно медленно. Это происходит из-за того, что при большом количестве одинаковых значений для INDEX поля происходит получение _всех_ записей из основной таблицы, которые соответствуют этому значению поля с INDEX (использование LIMIT не ускоряет работу с индексированными полями).

Юрий Насретдинов

deMone
Спасибо, посмотрю :)

Юрий Насретдинов

deMone
Если честно, мне кажется, что это совсем не то...

Ksnk

Юрий Насретдинов, если интересно, то немного повозившись с ff из svn'а мне удалось таки заставить его выполнить такое

Code (php):

скопировать код в буфер обмена

<?php
include "\workspace\ff\ff_conf.php";
ff_connect();
ff_select_db('db');
ff_query("DROP TABLE IF EXISTS `darts_users`;");
ff_query("CREATE TABLE `darts_users` (
`USER_ID` int(11) NOT NULL auto_increment,
`user` varchar(50) NOT NULL default '',
`password` varchar(50) default NULL,
`email` varchar(255) default NULL,
`realname` text,
`age` int(11) default '0',
PRIMARY KEY (`USER_ID`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 AUTO_INCREMENT=6 ;
");
ff_query("INSERT INTO `darts_users` VALUES (2, 'TEPKOM', 'qwerty', '', ', ,<br>,. 33-1', 0);");
ff_query("INSERT INTO `darts_users` VALUES (4, 'test', 'qwerty', ' Somethere in the space', 'Somethere in the space', 0);");
ff_query("INSERT INTO `darts_users` VALUES (5, 'test', 'test', '', '', 0);");
?>

Более содержательных тестов не проводилось, больно уж режут уже глаз всякие лишние глобальности ;-)

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

Code (any language):

скопировать код в буфер обмена

Index: Z:/workspace/ff/ff_insert.php
===================================================================
--- Z:/workspace/ff/ff_insert.php (revision 18)
+++ Z:/workspace/ff/ff_insert.php (working copy)
@@ -64,7 +64,7 @@
   $i = intval(key($db)) + $ci['auto_increment']['value'];
   $values[$pk] = $i;
   $GLOBALS['FF_LAST_INSERT_ID'] = $i;
- }elseif($db[$i]) return ff_set_error(3, $i);
+ }elseif(isset($db[$i])) return ff_set_error(3, $i);
   $db[$i] = $values;
   return ff_set_m_table($t);
}

Code (any language):

скопировать код в буфер обмена

Index: Z:/workspace/ff/ff_create.php
===================================================================
--- Z:/workspace/ff/ff_create.php (revision 18)
+++ Z:/workspace/ff/ff_create.php (working copy)
@@ -62,7 +62,7 @@
   $Q = ff_q();
   $regexp = '/CREATE\s+TABLE\s+(IF\s+NOT\s+EXISTS\s+)?/si';
   preg_match($regexp, $query, $match);
- $if_not_exists = (bool)$match[1];
+ $if_not_exists = isset($match[1])?(bool)$match[1]:false;
   $query = preg_replace($regexp, null, $query);
   preg_match("/($Q?)(\w+)\\1\s*$\s*(.*)\s*$/s", $query, $match);
   $t = $match[2];
@@ -72,8 +72,11 @@
   }
   $cols = ff_explode_gcg($match[3]);
   $type = 'INTEGER|(SMALL|TINY|MEDIUM|BIG)?INT|FLOAT|DOUBLE|REAL|DECIMAL|NUMERIC|DATE|TIME|DATETIME|TIMESTAMP|VARCHAR|CHAR|(TINY|MEDIUM|LONG)?(TEXT|BLOB)|ENUM|SET';
+ $primary_key=Array();
+ $columns=Array();
+ $types=Array();
   foreach($cols as $s){
- if(!preg_match("/(\w+)\s+($type)\s*(\s*$(.*?)$)?/i", $s, $match)) continue;
+ if(!preg_match("/$Q?(\w+)$Q?\s+($type)\s*($(.*?)$)?/i", $s, $match)) continue;
   $types[] = strtolower($match[2]);
   $columns[] = $match[1];
   $c = count($columns) - 1;
@@ -102,6 +105,7 @@
   return 1;
}
function ff_detect_primary_keys($columns, $query){
+ $Q = ff_q();
   preg_match("/PRIMARY\s+KEY\s*\(?$Q?(\w+)/si", $query, $match);
   $primary_key = array_search($match[1], $columns);
   return $primary_key;

Code (any language):

скопировать код в буфер обмена

Index: Z:/workspace/ff/ff_core.php
===================================================================
--- Z:/workspace/ff/ff_core.php (revision 18)
+++ Z:/workspace/ff/ff_core.php (working copy)
@@ -55,7 +55,7 @@
}
function ff_connect($s = '.'){
   register_shutdown_function('ff_close');
- global $FF_TABLES, $FF_M_TABLES, $FF_SERVER;
+ global $FF_TABLES, $FF_M_TABLES, $FF_SERVER, $FF_SERVER_PATH;
   if(!is_dir($FF_SERVER_PATH.$s)) return ff_set_error(502);
   $FF_SERVER = $s;
   $FF_TABLES = array();

Правда каким образом предполагается прикручивать все это к DB, я пока совершенно без никакого понятия ;-)

Юрий Насретдинов

Ksnk
В любом случае, спасибо за хоть какой-нибудь вклад в развитие проекта :)

Rumata

Юрий Насретдинов
Я согласен, что написать свою реализацию СУБД это здорово и интересно.
Но очень сомнительно, на мой взгляд, писать ее полностью на PHP.

Пока мне видится такая работа как проба собственных сил в весьма сложном проекте.

Юрий Насретдинов

Да, мне хотелось (и хочется) попробовать свои силы в очень сложном проекте :). При этом ничего на Си я писать не планировал, ибо весь смысл в таком случае потеряется...

Юрий Насретдинов

Ну и вдобавок к предыдущему: у Oracle есть реализация BerkleyDB целиком на Java :). www.oracle.com/database/berkeley-db/je/index.html

Rumata

случайно нашел сегодня xpoint.ru/forums/programming/theory_algorythms/thread/39763.xhtml

Юрий Насретдинов

Rumata
Да, спасибо, я видел это... Проблема в том, что это написание парсера SQL не входит в мои планы.

Юрий Насретдинов

В общем, проект, на самом деле, не совсем заброшен, но код действительно ужасен и требует переработки :).

Выкладываю версию с частично работающей функцией UPDATE, которую можно использовать, если у вас нету INDEX полей. Впрочем, почему-то UPDATE для UNIQUE полей тоже работает не совсем так, как ожидается (у меня она умудрялась находить данные и по старому и по новому ключам), так что лучше дождаться более стабильной версии :).

Протестировать работу базы Вы можете, создав папку data вместе с папкой со скриптом, и запустив тесты из test.php (для начала неплохо запустить CREATE [иначе будет выдаваться "File with table structure or with table data could not be read."], потом INSERT [иначе везде в качестве результатов вы будете видеть FALSE :)]).

Ни в коем случае не используйте эту версию ядра базы на production сервере и для хранения важных данных -- они могут быть утеряны! Скоро должна выйти версия, которая, по крайней мере, не портит индексы :).

YNDb-testing.zip

Description:

Download

Filename:

YNDb-testing.zip

Filesize:

23.37 KB

Downloaded:

683 Time(s)

Юрий Насретдинов

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

Прошу тех, кому интересно, попробовать написать тест для этой базы, который проверяет корректность работы базы, в том числе и операции UPDATE. Примеры подобных тестов можете посмотреть в файле test.php. Также есть UNIT-тест, который длится примерно 5 минут и тестирует множество операций и проверяет целостность базы после каждого существенного запроса.

YNDb-testing.zip

Description:

Следующая версия

Download

Filename:

YNDb-testing.zip

Filesize:

24.4 KB

Downloaded:

647 Time(s)

Юрий Насретдинов

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

Исходные файлы моего форума [ядро базы уже включено в архив]:

m.forum.dklab.ru/files/yuac_forum.zip (~180 Кб)

Экспортированная база сообщений:

m.forum.dklab.ru/files/forum_data.zip (~15,4 Мб) -- распакуйте содержимое в папку forum_data относительно index.php форума

Мне не хотелось заниматься перекодировкой дампа БД, поэтому вместо русских букв там везде вопросики, но на суть это не влияет :).

На форуме работает добавление новых сообщений, создание тем, просмотр форумов и тем (некоторые форумы и темы не откроются из-за того, что импорт был произведен напрямую из MySQL, и не все особенности хранения сообщений и тем были учтены).

Скажем, эта тема будет доступна по адресу polygon/yuac_forum/php/heap/6932.html, где polygon/yuac_forum/ -- это домен и название папки, в которую установлен (громко сказано, на самом деле просто файлы скопированы ;)) форум. Можно заметить, что сообщения идут не по порядку :). Но если вы добавите сообщение в эту тему, оно будет вставлено не в середину, а в конец :). То, что сообщения идут не по порядку -- это лишь особенность импорта базы.

Юрий Насретдинов

Если кому лень устанавливать форум себе, можете послать мне ЛС и я, скорее всего, пришлю вам ссылку на установленную версию форума, доступную из интернета.

nerezus

Quote:

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

Можно сделать хранимые процедуры, и на них написать интерпретатор пхп.
И на него портировать уже эту СУБД. С хранимыми процедурами. И на них тоже будет пхп.

А что, хорошая идея.

> интересно ли будет Вам использовать подобную базу данных в своих проектах?
Смысла нету. Совсем.
Если хочешь сделать пользу людям - то лучше sqlite доработал бы ;) Он это все может ;)

	Разное :: PHP :: Форум dkLab и Denwer Forum Index	All times are GMT + 3 Hours Goto page 1, 2 Next
Page 1 of 2		Email to a Friend.