file SQL v 1.0 (beta). Класс для работы с файловой базой данных

---- delete ----

---

Отредактировано администратором: EuGen, 31 Июля, 2013 - 13:29:22
Размещение прямых ссылок не допускается к размещению на конференции (см. правила конференции)

sqlite
?

-----
Есть в мире две бесконечные вещи - это Вселенная и человеческая глупость. Но насчет первой .. я не уверен.

SQLite - это модуль для PHP. А FileSQL - это обычная библиотека.

Не очень ясно, какая разница - обычная библиотека или модуль. Модуль будет установлен в 99% случаев на любом хостинге, тем более, что функционал там шире (начать следует хотя бы с того, что там - действительно используется SQL) - а стороннюю библиотеку нужно специально подключать в любом случае.
По поводу самого кода - думаю, пояснения и рецензирование составило бы объем, сопоставимый с объемом самого кода.

-----
Есть в мире две бесконечные вещи - это Вселенная и человеческая глупость. Но насчет первой .. я не уверен.

По сути не знаю в чем у Вас увеличилась скорость. По сути тот же Mysql хранит данние также в файлах. Хотя там есть оверхед на права доступа и парсинг запроса.

Тот же DDoS может убить MySQL сервер и сайт будет пуст. Файловая БД - решение этой проблемы.

Почему? В чём разница? Вы представляете себе, что такое DDoS?

-----
Есть в мире две бесконечные вещи - это Вселенная и человеческая глупость. Но насчет первой .. я не уверен.

При этом на PHP.
Это взаимоисключающие параграфы.
Весьма рекомендую прочитать книгу "MySQL. Оптимизация производительности" (Бэрон Шварц) и разобраться, где ваша проблема.

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

И вы используете json_encode, но класс в стиле PHP4 (объявление свойств с var, вместо public|protected|private).
Ну и SQL, заявленного в названии, тут нет.


А вы ляжете тут же, как пойдут параллельные транзакции на чтение и запись. Хорошо ещё, если без потери данных - не смотрел, реализуете ли вы блокировки.

-----
PostgreSQL DBA

Обьясните как ваша лыба решит DDoS. Ну например как у Вас с одновременным доступом? А с записью как? А если данных много, то что парсить весь файл заради ИД?
Я конечно за велосепелостроение, но увы ето не удачный вариант

(Отредактировано автором: 31 Июля, 2013 - 13:39:31)

Конечно представляю. Имел дело и не раз. По совместительству администрирую несколько ВДСок и выделенных серверов. (D)DoS на 3306 порт и MySQL ретурнит ошибку, т.к на него идет слишком много соединений. При этом апач в большинстве случаев (если это не UDP флуд) работает. Сайт остается без связи с БД
(Добавление)
Ну ясно. Тему можно закрывать. Смысла, как я вижу - нету.

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

А какого он у вас вообще внешний мир слушает?


С какой радости у вас апач публично доступен?

-----
PostgreSQL DBA

Для етого вешаем мускуль на localhost только и прощайте там всякые ДДоСы на мускуль

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

-----
Есть в мире две бесконечные вещи - это Вселенная и человеческая глупость. Но насчет первой .. я не уверен.

DDoS не делается на порт? Шутите?
TCP флуд (SYN например), слышали?

А MySQL внешний мир слушает, т.к он нужен для подключения клиентов через Navicat. Через PhpMyAdmin они не желают работать.

"С какой радости у вас апач публично доступен?"
А мне, что, на локалхост его вешать? Если он нужен для работы сайта в Интернете.
Да и Nginx'а нету, ибо не нужен еще.
(Добавление)
Тему можно закрыть, все ясно.

(Отредактировано автором: 31 Июля, 2013 - 13:47:50)

Ставить nginx.
Nginx - архитектурно предназначен для фронтэнда.
Apache - нет. Он хороший бекэнд, но ужасный фронтэнд.


Как с этим требованием уживается ваш класс?
Какие клиенты? Зачем вообще неуправляемый доступ к СУБД? Он нужен только администраторам и разработчикам - а их можно принудительно загнать в пул разрешённых IP (+ VPN для доступа с неизвестного места)

Это замечательно, что вы в 13 лет занялись программированием и в 15 администрируете несколько машин. Понимаю, возраст. Но прислушивайтесь к критике.

-----
PostgreSQL DBA