Версия для печати темы Нажмите сюда для просмотра этой темы в оригинальном формате

Форум программистов > PHP: Базы Данных > class DataBase

Автор: Zorak 17.3.2013, 19:52

Здраствуйте дамы и господа. У меня вопрос чисто теоретический.... пока Написал класс, который отвечает за работу с базой данных на страницах моего сайта. Вот некоторые методы класса: 1. __construct() - обеспечивает соединение с базой данных 2. __destruct() - обеспечивает закрытие существующего соеднения с базой данных 3. методы select(), insert(), update(), delete() - тут и так все понятно. За иронией судьбы (так сказать)  я подключаю этот класс на каждой странице и в некоторых классах, где он мне требуется. Естессно при создании обьекта класса происходит подключение к базе данных, далее браузеру передается сгенерированная страница по коду, ну и в конце уничтожается обьект класса, в следствии чего и разрывается соединение с базой данных. И таким макаром происходит на каждой странице. Проблема в том, что я некоторым чутьем чуствую что гдето промахнулся, а в друг потом напишу несколько страниц, где будут пересекатся разные классы и обьект класса DataBase создастся два раза а того более хуже больше чем два...  И так, вопроса два: 1. Чем это чревато? 2. как это исправить ? (хотябы куда и под каким углом смотреть). Не хочется потом переписывать фиг знает что и сколько... Спасибо!

Автор: Gold Dragon 18.3.2013, 07:39

ну  для класса базы данных тебе нужно воспользоваться шаблоном проектирования Singleton. Т.е. Объект создаётся всего один раз.. Вот примерная структура Код class GDDatabase {     /** @var string - хост */     private $_db_host;     /** @var string - пользователь */     private $_db_user;     /** @var string - пароль */     private $_db_password;     /** @var string - имя БД */     private $_db_name;     /** @var string - порт */     private $_db_port;     /** @var string - сокет */     private $_db_socket;     /** @var int - флаг отладки */     private $_db_debug;     /** @var int - флаг кэширования */     private $_db_caching;     /** @var string - префикс для таблиц */     private $_db_prefix;     /** @var string - путь до файлов кэширования */     private $_db_cache_dir;     /** @var int - время кэширования */     private $_db_cache_time;     /** @var null|object - интерфейс */     protected static $_resource = null;     /** @var \mysqli - MySQLi object */     protected $db_resource;     /** @var \mysqli_stmt - MySQLi_STMT object */     protected $stmp;     /***************************************************************************      * Magic methods     /***************************************************************************/     /**      * Конструктор      * Защищаем от создания через new      */     private function __construct()     {         // Сохранение основных настроек         // т.е. достаём из конфигурации настройки для подключения к БД и сохраняем их         $this->_db_host = JCore::getCfg('host');         $this->_db_user = JCore::getCfg('user');         $this->_db_password = JCore::getCfg('password');         $this->_db_name = JCore::getCfg('db');         $this->_db_port = JCore::getCfg('port');         $this->_db_socket = JCore::getCfg('socket');         $this->_db_debug = JCore::getCfg('debug');         $this->_db_caching = JCore::getCfg('caching');         $this->_db_prefix = JCore::getCfg('dbprefix');         $this->_db_cache_dir = JCore::getCfg('cachepath');         $this->_db_cache_time = JCore::getCfg('cachetime');         // Проверка существует ли вообще функция подключения         if (!function_exists('mysqli_connect')) {             throw new Exception(_EXCEP_MYSQLI_MODULE_NOT);         }         // Временно отключаем вывод ошибок         $_error = error_reporting();         error_reporting(0);         // Создаём объект базы         $this->db_resource = new mysqli(             $this->_db_host,             $this->_db_user,             $this->_db_password,             $this->_db_name,             $this->_db_port,             $this->_db_socket);         if ($this->db_resource->connect_error) {             throw new Exception(_EXCEP_ERROR_CONNECT_DB);         }         // Возвращаем состояние вывода ошибок         error_reporting($_error);         // Устанавливаем кодировку         if (!$this->db_resource->set_charset('utf8')) {             throw new Exception(sprintf(_EXCEP_ERROR_LOADING_CHARACTER_SET, $this->db_resource->character_set_name()));         }         // записываем логи запросов         if ($this->_db_debug) {             $this->db_resource->query('set profiling=1');             $this->db_resource->query('set profiling_history_size=100');         }     }     /**      * Защищаем от создания через клонирование      */     private function __clone()     {     }     /**      * Защищаем от создание через unserialize      */     private function __wakeup()     {     }     /**      * @static Подключение класса      *      * @return object      */     public static function Init()     {         if (!is_object(self::$_resource)) {             $class_name = __CLASS__;             self::$_resource = new $class_name;         }         return self::$_resource;     } } использовать можно так Код $_db = GDDatabase::Init(); Т.е. объект создаётся один раз, а все остальные подключения просто возвращают то что уже создано ну  и дальше твои методы Код $_db->select ..... $_db->insert ..... или  сразу Код GDDatabase::Init()->select .... GDDatabase::Init()->insert .... ps если вдруг что, то вот мой класс-обёртка    https://code.google.com/p/gddatabase/

Автор: Zorak 18.3.2013, 09:12

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

Автор: ksnk 18.3.2013, 09:39

Zorak, Мне отчего-то нравятся функции драйвера базы данных, которые возвращают не рессурсы, а данные. Интерфейс получается, кроме служебных конструкторов-деструкторов еще и  insert - возвращает количество вставленных строк update - количество измененных строк. select - возвращает массив массивов строк selectCell - одно значение selectCol - столбец - массив значений selectRow - строка Так получится менее затратно переходить на новый драйвер базы данных. с mysql, например на mysqli.

Автор: Gold Dragon 18.3.2013, 10:08

ksnk, однозначно ! А иначе для чего нужна обёртка    а ещё вот какие: selectAll - получить все данные указав только таблицу getCacheSql - ну это запрос к базе, но при использовании кэширования getQueryInfo - получение дополнительной информации о запросе (количество строк, затронутых последним запросом, ID предыдущей операцией INSERT, число строк в результате запроса, число полей в заданном выражении, ошибка последнего запроса и т.п.) соответственно ещё  getError getErrno ЗЫ у меня в классе это всё реализовано. Да и используются подготовленные данные, так что нет смысла что-то экранировать и бояться

Автор: Sanchezzz 18.3.2013, 11:52

А я сижу делаю обертку вокруг PDO для своего микро фреймворка Поделюсь с задумкой а может для кого то идеями. Есть класс db - это коллекция синглитон адаптеров, которые работают с разными СУБД, NOSQL С какой базой данной работать определяется конфигом в виде массива.  db::make() - загрузка настройки по умолчанию, db::make('mongo') загрузка указанной настройки. dbPdo Обертка над PDO dbMongo Обердка над монго.  Работа с БД происходит точно также как и с обычным PDO за  исключением того что все методы можно вызвать цепочкой, меня жутко бесило это  в обычном PDO что это нельзя было это сделать. $db = db::make(); $db->cache($duration)->prepare ... работа с кэшем, кэш также определяется в конфиге к БД, как и профайлер, логер. $db->prepare($sql)->execute(array(':id',1))  ->fetchAll()  // результат все ->fetch()     // первоя строка + курсор в цикде. ->fetchCulumn($column_name) // результат указанный столбец ->asModel()  // результат в виде AR модели или ее подобие (допиливаю последнее время) $db->prepare($sql) ->bindValue  ->bindParam  ->execute()  ->fetchAll Эмуляция плейхостов нужна для логера и дебагера. $db->saveModel($this_class); // сохранить указанную AR модель под текущую БД. Под каждую БД приходится писать свои костыли что бы сохранить модель. // Модель нечего нечего не знает о базе.  // Модель спроектирована уже с необходимой структурой и связями. $db->query($prepare,$execute,$debug=false); // результат INSERT UPADETE SELECT DELETE $db->insert($table, $arraySet); $db->update($table, $arraySet);

Автор: Fortop 18.3.2013, 14:48

Цитата(Gold Dragon @  18.3.2013,  07:39 ) ну  для класса базы данных тебе нужно воспользоваться шаблоном проектирования Singleton. Разве? А я думал что он нужен для подключения/адаптера, и то не всегда

Автор: Gold Dragon 18.3.2013, 14:52

Цитата(Fortop @  18.3.2013,  15:48 ) А я думал что он нужен для подключения/адаптера, и то не всегда  а по понятнее?

Автор: Fortop 18.3.2013, 16:42

По понятнее? Избежать множества запросов синглтоном нельзя. Но избежать множества открытий/закрытий соединения - можно. Вся привычка делать класс работы с БД синглтоном базируется как раз на этой логике. А раз так... то делаем синглтоном класс подключения/адаптера и используем его в своих обертках. Код // one.php $db = new SuperWrapper(Connection::getInstance()); $db->query(......) // two.php $somewhereElse = new DuperWrapper(Connection::getInstance());

Автор: baldina 18.3.2013, 17:32

Цитата(Fortop @  18.3.2013,  16:42 ) А раз так... то делаем синглтоном класс подключения/адаптера и используем его в своих обертках. и в чем разница/выигрыш?

Автор: Fortop 18.3.2013, 17:45

Цитата(baldina @  18.3.2013,  17:32 ) и в чем разница/выигрыш?  Разница в архитектуре. А вот выигрыш - вопрос спорный  Несколько более гибкое приложение, при условии развитого DBAL

Автор: baldina 18.3.2013, 17:51

Цитата(Fortop @  18.3.2013,  17:45 ) Несколько более гибкое приложение а если потребуется еще одно соединение? Добавлено через 7 минут и 7 секунд синглтон - не архитектура, а индивидуальное, редко полезное решение. любая архитектура на его основе плохо масштабируется. хорошая архитектура (в частности) - это когда есть согласованная структура приложения и его частей, каждая из которых отвечает за своё. тогда не понадобятся синглтоны, а повсеместные $db = new myDb() или $db = myDb::getInstance() превратятся в $app->getDb()

Автор: Fortop 18.3.2013, 22:14

Цитата(baldina @  18.3.2013,  17:51 ) а если потребуется еще одно соединение? Модифицируем до пула. Или низводим с уровня синглтона соединения вообще и используем Registry для их хранения

Автор: baldina 18.3.2013, 23:11

Цитата(Fortop @  18.3.2013,  22:14 ) Модифицируем до пула. массив-синглтон? массив синглтонов? масло масляное Цитата(Fortop @  18.3.2013,  22:14 ) используем Registry который тоже синглтон? имеем кучку синглтонов, т.е. глобальных переменных, угу... потом обнаруживаются проблемы с последовательностью их инициализации

Автор: Fortop 19.3.2013, 02:11

Цитата(baldina @  18.3.2013,  23:11 ) массив-синглтон? массив синглтонов? масло масляное А кроме личных предпочтений к ношению розовых бикини аргументация будет?    Цитата(baldina @  18.3.2013,  23:11 ) потом обнаруживаются проблемы с последовательностью их инициализации С последовательностью инициализации кого? Соединений с БД?

Автор: ksnk 19.3.2013, 08:25

Вообще-то все драйвера и обертки нужны для того, чтобы писать красиво   То есть сначала нужно придумать как это будет написано, а потом уже реализовать, если это возможно. Fortop предлагает писать так: Код // one.php $db = new SuperWrapper(Connection::getInstance()); $db->query(......) // two.php $somewhereElse = new DuperWrapper(Connection::getInstance()); А baldina как предпочитает видеть этот кусок?

Автор: baldina 19.3.2013, 10:16

ksnk, дело вовсе не в драйверах и не обертках. это вопрос не вкуса, а архитектуры. важно не как оно выглядит (это тоже важно, но во вторую очередь), а как структурно устроено. я сказал, что singleton это плохо масштабируемое решение, поэтому должен применяться как лекарственный яд - строго по назначению малыми дозами. Цитата(Fortop @  19.3.2013,  02:11 ) Цитата(baldina @  18.3.2013,  23:11 ) потом обнаруживаются проблемы с последовательностью их инициализации С последовательностью инициализации кого? к несчастью к php это в малой степени относится (к несчастью - потому что провоцирует на применение). в php проблема возникает лишь в случае зависимости объектов, при которой требуется определенный порядок инициализации. в случае решения на основе синглтонов некому этот порядок обеспечить и контролировать. я вижу решение в использовании единственного "как бы" синглтона - объекта типа Application, который и порядок инициализации обеспечивает, и предоставляет доступ к объектам, глобальным в контексте приложения, и сам является масштабируемым. Добавлено через 5 минут и 23 секунды Цитата(ksnk @  19.3.2013,  08:25 ) А baldina как предпочитает видеть этот кусок?  Цитата(baldina @  18.3.2013,  17:51 ) $app->getDb()  т.е. как угодно, но получая соединение из объекта приложения Код $db = new SuperWrapper($app->getDb()); // or $db = $app->getSuperWrapperDb(); // or $db = $app->getDb()->applyWrapper('Super');

Автор: Fortop 19.3.2013, 13:19

Цитата(baldina @  19.3.2013,  10:16 ) я вижу решение в использовании единственного "как бы" синглтона - объекта типа Application, который и порядок инициализации обеспечивает, и предоставляет доступ к объектам, глобальным в контексте приложения, и сам является масштабируемым. Наводящий вопрос. Каким образом оно масштабируется? Добавлено через 1 минуту и 57 секунд Цитата(ksnk @  19.3.2013,  08:25 ) Вообще-то все драйвера и обертки нужны для того, чтобы писать красиво  Увы, не для "красиво". А для того, чтобы не было мучительно больно в процессе поддержки и расширения приложения

Автор: baldina 19.3.2013, 13:36

Цитата(Fortop @  19.3.2013,  13:19 ) Каким образом оно масштабируется? добавлением метода в класс Application само приложение может быть масштабировано созданием нескольких объектов Application (хотя к задачам веб это думаю не относится))

Автор: Fortop 19.3.2013, 17:01

Цитата(baldina @  19.3.2013,  13:36 ) само приложение может быть масштабировано созданием нескольких объектов Application Итого? получаем кучку тех же самых синглтонов?    В чем тут отличие от масштабирования приложений на пхп? И как порядок инициализации может мешать подобному масштабированию?

Автор: ksnk 19.3.2013, 17:33

Цитата(Fortop @  19.3.2013,  13:19 ) Увы, не для "красиво". Красота не бывает абстрактной. Она обязана приносить пользу    В программировании "красивая" польза будет -- поддержка проекта, в дальнейшем, чужими людьми. Решается достаточной документацией и комментариями. -- возможность дальнейшего роста проекта, добавление новых возможностей, фич. Решается проектированием и выбором масштабируемых решений. -- повторная используемость кода. Это когда код (классы, функции и кусочки кода) в меру тупо и без особых изменений могут быть скопированы в другой, новый проект и там заработают правильно и достаточно эффективно.  Вот эта третья красивость тянет за собой минимизацию зависимостей от окружения. Слова, которые определяются в других классах-функциях, должны по возможности исключаться, или быть изолированы в отдельном месте класса - функции... Так чтобы это не противоречило остальным факторам "красивого кода".

Автор: baldina 19.3.2013, 18:30

Цитата(Fortop @  19.3.2013,  17:01 ) Цитата(baldina @  19.3.2013,  13:36 ) само приложение может быть масштабировано созданием нескольких объектов Application Итого? получаем кучку тех же самых синглтонов? они уже не синглтоны, в том то и дело  В чем тут отличие от масштабирования приложений на пхп? не php, а web. и если бы были, уже кто-нить придумал бы соотв. архитектурное решение пример: приложение как расчетный модуль. если приложение организовано через единственный объект, можно завести еще один объект и параллельно решать две однотипные задачи. а если приложение содержит ряд синглтонов (или просто глобальных переменных)?  Цитата(Fortop @  19.3.2013,  17:01 ) И как порядок инициализации может мешать подобному масштабированию?    порядок инициализации может мешать масштабированию, если он требуется, но никто им не управляет

Автор: Fortop 19.3.2013, 18:58

Цитата(baldina @  19.3.2013,  18:30 ) приложение как расчетный модуль. если приложение организовано через единственный объект, можно завести еще один объект и параллельно решать две однотипные задачи. а если приложение содержит ряд синглтонов (или просто глобальных переменных)?  В php нет тредов. Поэтому завести еще один объект и решать параллельно можно только вместе с новым процессом. А поскольку процессы между собой изолированы, то никаких сложностей не возникает (если вы, конечно, не применяли ухищрений, например, с shmop) ни с рядом синглтонов, ни с глобальными переменными. Цитата(baldina @  19.3.2013,  18:30 ) порядок инициализации может мешать масштабированию, если он требуется, но никто им не управляет  Это не относится к работе синглтонов, пула и т.п. в рамках скрипта. Т.е. либо порядок инициализации никак не влияет на работу приложения и соответственно свободно масштабируем. Или если порядок инициализации мешает масштабированию, то в случае с php скорее всего ваш скрипт нерабочий даже в единственном числе (хотя и есть нюансы, например, связанные с эксклюзивным доступом к каким-либо ресурсам системы)

Автор: Gold Dragon 19.3.2013, 19:34

Fortop, что в твоём понимании масштабирование..? Просто читаю и чем больше, тем хуже начинаю понимать    Цитата(Fortop @  19.3.2013,  19:58 ) хотя и есть нюансы, например, связанные с эксклюзивным доступом к каким-либо ресурсам системы а доступ к базе данных к этому не относится?

Автор: baldina 19.3.2013, 19:37

Цитата(Fortop @  19.3.2013,  18:58 ) В php нет тредов. во-первых, параллельно можно работать кооперативно. во-вторых, речь шла об архитектуре вообще Цитата(Fortop @  19.3.2013,  18:58 ) в случае с php скорее всего ваш скрипт нерабочий даже в единственном числе да. причем не рабочим он может быть далеко не на первый взгляд, и предстоит веселая отладка. Добавлено через 7 минут и 8 секунд Цитата(baldina @  19.3.2013,  19:37 ) параллельно можно работать кооперативно собственно все даже проще: в достаточно сложном приложении есть немало одинаковых мест, каждое из которых должно выполняться в своём контексте. зависимость от синглтона делает его неотъемлемой частью любого контекста, ввод нового контекста - заплатки и костыли. глобальный контекст, как правило, существует - это контекст приложения. он (контекст) может быть размазан по файлам, объектам (синглтонам), глобальным переменным. это допустимо, но усложняет внесение изменений, тем более расширение. сбор всего этого добра в одном месте - упрощает. в последнем случае техника синглтона не требуется.

Автор: baldina 19.3.2013, 19:58

итог: создание экземпляра объекта db и т.п. и его предоставление приложению - дело не библиотеки (доступа к бд), а приложения. т.к. библиотека не знает в рамках какой архитектуры она будет работать, а предоставление синглтона на уровне библиотеки (тем более без возможности альтернативного создания объекта) как минимум стимулирует неправильное использование в рамках конкретной архитектуры. (для простых приложений возможность использования контекста по умолчанию удобно, как это устроено в php_mysql. в процедурном стиле mysqli от этого отказались, т.к. ножик острый)

Автор: Fortop 19.3.2013, 23:13

Цитата(Gold Dragon @  19.3.2013,  19:34 ) Fortop, что в твоём понимании масштабирование..? Просто читаю и чем больше, тем хуже начинаю понимать    В смысле? Масштабирование это увеличение используемых для решения задачи ресурсов. Фокус в том, что для многих языков оно доступно через многозадачность в потоках. Но php не поддерживает подобное решение (и это во многом его плюс). Т.е. любое масштабирование задачи на php сводится к запуску дополнительных копий скрипта (на этой машине или многих других машинах - не суть важно). Поэтому у задач на пхп обычно нет тех проблем, на которые пытался ссылаться baldina. Т.е. конечный php-скрипт с его пространством имен и есть тот самый Application В многих других языках все не так просто. Цитата(Gold Dragon @  19.3.2013,  19:34 ) а доступ к базе данных к этому не относится? Нет, обычно не относится, поскольку база поддерживает множество подключений. Добавлено через 5 минут и 17 секунд Цитата(baldina @  19.3.2013,  19:37 ) в достаточно сложном приложении есть немало одинаковых мест, каждое из которых должно выполняться в своём контексте. зависимость от синглтона делает его неотъемлемой частью любого контекста, ввод нового контекста - заплатки и костыли. Это все справедливо. В частности поэтому я обратил внимание на то, что класс работы с БД не обязан быть синглтоном  Но применительно к области применения php и конкретно соединения с БД - стараются минимизировать их число для приложения. Поэтому Цитата(Fortop @  18.3.2013,  14:48 ) А я думал что он нужен для подключения/адаптера, и то не всегда Обращаю внимание на фразу "и то не всегда". Т.е. подключение/адаптер не всегда обязан быть синглтоном

Автор: Gold Dragon 19.3.2013, 23:36

Цитата(Fortop @  20.3.2013,  00:13 ) Масштабирование это увеличение используемых для решения задачи ресурсов. аа, значит правильно понял.. А зачем мне расширять ресурсы??? Я смотрел много движков где это закладывается, но реально это вообще или очень и очень редко используется... Вот для фреймворков может быть это актуально. А вот для движка для моего сайта вообще не нужно... Я написал класс для управления базой что он и делает... А масштабирование это не только для меня увеличение человека/часов, но и выброшенные деньги   Так что мера должна быть в желаниях Цитата(Fortop @  20.3.2013,  00:13 ) что класс работы с БД не обязан быть синглтоном  да конечно не обязан(!), но как правило является таковым для простых вопросов (и даже не очень)  т.к. не нужно ни масштабирование ни множественное подключение

Автор: Fortop 19.3.2013, 23:47

Цитата(Gold Dragon @  19.3.2013,  23:36 ) А зачем мне расширять ресурсы??? Конкретно тебе? Без понятия. А у нас на 300к уников в сутки виртуалка впала в ступор, пришлось поднимать еще две.

Автор: baldina 20.3.2013, 10:25

Цитата(Fortop @  19.3.2013,  23:13 ) Масштабирование это увеличение используемых для решения задачи ресурсов. почти))) увеличение ресурсов - средство, а не цель. цель - увеличение производительности/числа решаемых задач. еще можно масштабировать функционал. в последнем случае в применении к пхп уместен пример перерастания микрофреймворка в монстрофреймворк, который будет успешен при удачной архитектуре исходника.

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)