Здраствуйте дамы и господа. У меня вопрос чисто теоретический.... пока
Написал класс, который отвечает за работу с базой данных на страницах моего сайта.
Вот некоторые методы класса:
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 для их хранения

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

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

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

  

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


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

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


А baldina как предпочитает видеть этот кусок?

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


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

я вижу решение в использовании единственного "как бы" синглтона - объекта типа Application, который и порядок инициализации обеспечивает, и предоставляет доступ к объектам, глобальным в контексте приложения, и сам является масштабируемым.

Добавлено через 5 минут и 23 секунды


т.е. как угодно, но получая соединение из объекта приложения

Наводящий вопрос.

Каким образом оно масштабируется?

Добавлено через 1 минуту и 57 секунд

Увы, не для "красиво". А для того, чтобы не было мучительно больно в процессе поддержки и расширения приложения 

добавлением метода в класс Application
само приложение может быть масштабировано созданием нескольких объектов Application (хотя к задачам веб это думаю не относится))

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

Красота не бывает абстрактной. Она обязана приносить пользу   

В программировании "красивая" польза будет
-- поддержка проекта, в дальнейшем, чужими людьми. Решается достаточной документацией и комментариями.
-- возможность дальнейшего роста проекта, добавление новых возможностей, фич. Решается проектированием и выбором масштабируемых решений.
-- повторная используемость кода. Это когда код (классы, функции и кусочки кода) в меру тупо и без особых изменений могут быть скопированы в другой, новый проект и там заработают правильно и достаточно эффективно. 

Вот эта третья красивость тянет за собой минимизацию зависимостей от окружения. Слова, которые определяются в других классах-функциях, должны по возможности исключаться, или быть изолированы в отдельном месте класса - функции... Так чтобы это не противоречило остальным факторам "красивого кода".


Это сообщение отредактировал(а) ksnk - 19.3.2013, 17:34

не php, а web. и если бы были, уже кто-нить придумал бы соотв. архитектурное решение
пример: приложение как расчетный модуль. если приложение организовано через единственный объект, можно завести еще один объект и параллельно решать две однотипные задачи. а если приложение содержит ряд синглтонов (или просто глобальных переменных)? 


порядок инициализации может мешать масштабированию, если он требуется, но никто им не управляет

В php нет тредов.
Поэтому завести еще один объект и решать параллельно можно только вместе с новым процессом.

А поскольку процессы между собой изолированы, то никаких сложностей не возникает (если вы, конечно, не применяли ухищрений, например, с shmop) ни с рядом синглтонов, ни с глобальными переменными.


Это не относится к работе синглтонов, пула и т.п. в рамках скрипта.

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

Fortop, что в твоём понимании масштабирование..? Просто читаю и чем больше, тем хуже начинаю понимать   

а доступ к базе данных к этому не относится?

во-первых, параллельно можно работать кооперативно. во-вторых, речь шла об архитектуре вообще


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

Добавлено через 7 минут и 8 секунд

собственно все даже проще: в достаточно сложном приложении есть немало одинаковых мест, каждое из которых должно выполняться в своём контексте. зависимость от синглтона делает его неотъемлемой частью любого контекста, ввод нового контекста - заплатки и костыли.

глобальный контекст, как правило, существует - это контекст приложения. он (контекст) может быть размазан по файлам, объектам (синглтонам), глобальным переменным. это допустимо, но усложняет внесение изменений, тем более расширение. сбор всего этого добра в одном месте - упрощает. в последнем случае техника синглтона не требуется.

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

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

Это сообщение отредактировал(а) baldina - 19.3.2013, 19:59

В смысле?
Масштабирование это увеличение используемых для решения задачи ресурсов.

Фокус в том, что для многих языков оно доступно через многозадачность в потоках.
Но php не поддерживает подобное решение (и это во многом его плюс).
Т.е. любое масштабирование задачи на php сводится к запуску дополнительных копий скрипта (на этой машине или многих других машинах - не суть важно).
Поэтому у задач на пхп обычно нет тех проблем, на которые пытался ссылаться baldina.

Т.е. конечный php-скрипт с его пространством имен и есть тот самый Application
В многих других языках все не так просто.


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

Добавлено через 5 минут и 17 секунд

Это все справедливо. В частности поэтому я обратил внимание на то, что класс работы с БД не обязан быть синглтоном 
Но применительно к области применения php и конкретно соединения с БД - стараются минимизировать их число для приложения.

Поэтому


Обращаю внимание на фразу "и то не всегда".
Т.е. подключение/адаптер не всегда обязан быть синглтоном 

аа, значит правильно понял.. А зачем мне расширять ресурсы??? Я смотрел много движков где это закладывается, но реально это вообще или очень и очень редко используется... Вот для фреймворков может быть это актуально. А вот для движка для моего сайта вообще не нужно... Я написал класс для управления базой что он и делает... А масштабирование это не только для меня увеличение человека/часов, но и выброшенные деньги   Так что мера должна быть в желаниях

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

Конкретно тебе? Без понятия.

А у нас на 300к уников в сутки виртуалка впала в ступор, пришлось поднимать еще две.

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