Класс для работы с MySQL, class DB

У вас база называется /dev/null ? Раз данные никогда не выводятся

А что вообще в конечном итоге делает класс? Только чтобы сделать класс?
защиты данных - нет
абстракции от драйвера СУБД - нет
возможности в случае нужды поднять второй линк к БД (например, к другому серверу) - нет
только форматирование результата в массив - 1 функция.
защиты от создания второго соединения по одним и темже параметрам - нет.
сокращение кода - нет

(Отредактировано автором: 12 Марта, 2011 - 21:04:01)

-----
PostgreSQL DBA

Черная дыра))
Ниче, сейчас DeepVarvar учтет все пинки и сделает мега класс для работы с БД.

1) Забыл про mysqli
2) Ленивый я, чтоб каждую переменную проводить через функцию, было бы хорошо, если бы за меня делалось бы.
3) Лучше, чтоб передавался идентификатор подключения к БД, а не логин, пароль и т.д.
4) Возвращение массива лучше по запросу, а так просто отдавать результат, как от mysql_query

нет, не согласен. Зачем тогда класс, если соединение устанавливать отдельно?


Согласен. И метод-обёртка для mysql_fetch_assoc. Всё равно же в цикле как правило пробегать ответ.

Для защиты от SQL инъекций мне больше всего симпатизирует реализация такой функции: первый обязательный аргумент - текст запроса, любое количество следующий - данные, вставляющиеся в запрос после прохождения mysql_real_escape_string, например, через sprintf.
В таком случае защита получается ненавязчивой и можно как самому, так и автоматикой экранировать данные.

-----
PostgreSQL DBA

Не сейчас, а со временем.

Ситуация:
Произошла ошибка. Записана в лог-массив.
Далее в коде несколько условий if (error::$init)
Как сделать чтобы оно в одном из них (в зависимости от необходимости) не сработало?

Нет, Champion неверно выразился. Смотрите код.

Вход? Выход? Внутренний приват?

Тут подробнее, пожалуйста.

И не предусматривалось.

Именно этим сейчас занимаюсь.

Сначала не подходило то, что возвращалась переменная если 1 ров и 1 филд.
Теперь и выбор не устраивает?

З.Ы. Ни грамма негатива в вашу (это всем) сторону.
(Добавление)

Допер до этого сам... Переделываю...

-----
Шта? Репозиторий?

Имелась в виду, конечно, автозащита. Входных от SQL-инъекций.


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


и как с людьми жить, да?

Кстати, сделай __destruct с закрытием коннекта. Всё-таки так кошернее, когда коннект закрывается

-----
PostgreSQL DBA

Это чтение свойства. Можно сделать публичный метод getInit(), который будет его возвращать.
Если свойство публичное, то я смогу его изменить в своей проге. Потом что-то может произойти некорректно, особенно, если методы класса этим свойством пользуются. Поэтому свойства нужно делать приватными. Есть конечно некоторые моменты, когда можно сделать их публичными, но тут не такой случай.
Самая главная штука ООП - инкапсуляция. Это значит, что класс скрывает все детали реализации и предоставляет пользователю легкий, не большой и понятный интерфейс к себе, но не более того. Класс, в котором есть публичные свойства при использовании вызывает чувство неуверенности и действия, производимые над этим классом плохо контролируются.

Ненене. Не понравилось сначала то, что функция ведет себя по-разному. А теперь пришло в голову улучшение: возможность возвращать не массив, а линк. Только лучше пусть это делает другая функция, а не всё одна с параметром.
Просто бывают случаи, когда пользователю нужно не просто получить строки таблицы, а каким-нибудь замысловатым способом. Тогда возвращать ему массив, чтоб он его потом перерабатывал - не оптимально

Как я должен использовать возможности MYSQL не описанные в классе? Или описанные не так, как мне нужно?


Плохо, мне очень часто, бывает необходимо работать с 2-3 базами, вот, как я буду работать.


P.S. Реально использование класса сейчас чем отличается от использования стандартных методов?
1) Данный класс только ограничивает стандартные возможности.
2) Защита от SQL - функция, в названии, немного короче: clean() и mysql_real_escape_string() - притом твой вариант менее стабильный будет.
3) Удобности пока действительно нет.