Здраствуйте дамы и господа. У меня вопрос чисто теоретический.... пока
Написал класс, который отвечает за работу с базой данных на страницах моего сайта.
Вот некоторые методы класса:
1. __construct() - обеспечивает соединение с базой данных
2. __destruct() - обеспечивает закрытие существующего соеднения с базой данных
3. методы select(), insert(), update(), delete() - тут и так все понятно.

За иронией судьбы (так сказать)  я подключаю этот класс на каждой странице и в некоторых классах, где он мне требуется. Естессно при создании обьекта класса происходит подключение к базе данных, далее браузеру передается сгенерированная страница по коду, ну и в конце уничтожается обьект класса, в следствии чего и разрывается соединение с базой данных. И таким макаром происходит на каждой странице.
Проблема в том, что я некоторым чутьем чуствую что гдето промахнулся, а в друг потом напишу несколько страниц, где будут пересекатся разные классы и обьект класса DataBase создастся два раза а того более хуже больше чем два... 
И так, вопроса два:
1. Чем это чревато?
2. как это исправить ? (хотябы куда и под каким углом смотреть).

Не хочется потом переписывать фиг знает что и сколько...

Спасибо!

ну  для класса базы данных тебе нужно воспользоваться шаблоном проектирования Singleton. Т.е. Объект создаётся всего один раз.. Вот примерная структура



использовать можно так

Т.е. объект создаётся один раз, а все остальные подключения просто возвращают то что уже создано

ну  и дальше твои методы



или  сразу




ps
если вдруг что, то вот мой класс-обёртка   
https://code.google.com/p/gddatabase/

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

Zorak, Мне отчего-то нравятся функции драйвера базы данных, которые возвращают не рессурсы, а данные.
Интерфейс получается, кроме служебных конструкторов-деструкторов еще и 

• insert - возвращает количество вставленных строк
• update - количество измененных строк.
  
• select - возвращает массив массивов строк
• selectCell - одно значение
• selectCol - столбец - массив значений
• selectRow - строка

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

Это сообщение отредактировал(а) ksnk - 18.3.2013, 09:40

ksnk, однозначно ! А иначе для чего нужна обёртка   

а ещё вот какие:

• selectAll - получить все данные указав только таблицу
• getCacheSql - ну это запрос к базе, но при использовании кэширования
• getQueryInfo - получение дополнительной информации о запросе (количество строк, затронутых последним запросом, ID предыдущей

операцией INSERT, число строк в результате запроса, число полей в заданном выражении, ошибка последнего запроса и т.п.)

соответственно ещё 

• getError
• getErrno

ЗЫ
у меня в классе это всё реализовано. Да и используются подготовленные данные, так что нет смысла что-то экранировать и бояться   


Это сообщение отредактировал(а) Gold Dragon - 18.3.2013, 10:09

А я сижу делаю обертку вокруг 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);

Разве?

А я думал что он нужен для подключения/адаптера, и то не всегда 

а по понятнее?

По понятнее?

Избежать множества запросов синглтоном нельзя.
Но избежать множества открытий/закрытий соединения - можно.

Вся привычка делать класс работы с БД синглтоном базируется как раз на этой логике.
А раз так... то делаем синглтоном класс подключения/адаптера и используем его в своих обертках.

и в чем разница/выигрыш? 

Это сообщение отредактировал(а) baldina - 18.3.2013, 17:32

Разница в архитектуре.

А вот выигрыш - вопрос спорный 
Несколько более гибкое приложение, при условии развитого DBAL

а если потребуется еще одно соединение?

Добавлено через 7 минут и 7 секунд
синглтон - не архитектура, а индивидуальное, редко полезное решение.
любая архитектура на его основе плохо масштабируется.

хорошая архитектура (в частности) - это когда есть согласованная структура приложения и его частей, каждая из которых отвечает за своё. тогда не понадобятся синглтоны, а повсеместные $db = new myDb() или $db = myDb::getInstance() превратятся в $app->getDb()

Модифицируем до пула.
Или низводим с уровня синглтона соединения вообще и используем Registry для их хранения

массив-синглтон? массив синглтонов? масло масляное

который тоже синглтон?

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

  

А кроме личных предпочтений к ношению розовых бикини аргументация будет?   


С последовательностью инициализации кого?
Соединений с БД?