Комментарии 16
хабракат!
писал я это, исключительно для себя. цели открыть кому-то(кроме себя) глаза на что-то не преследовалось(что собственно следовало из названия топика). интересно было услышать комментарии и замечания(что следовало из текста в конце поста) по поводу того, что использую каждый день.
большое спасибо за ссылки. бегло пробежавшись по DbSimple, увидел много преимуществ над своим детищем.
большое спасибо за ссылки. бегло пробежавшись по DbSimple, увидел много преимуществ над своим детищем.
Пользуюсь DbSimple, не могу сказать, что всем доволен, но чем ваша библиотека лучше и почему кто-то должен ею пользоваться? Иными словами, в чём преимущества именно вашей разработки?
Удинственный недостаток класса DbSimple, на мой взгляд, медленная (относительно) скорость работы, что не всегда позволяет использовать его на сильно загруженных проектах. Однако, удобство использования ставит эту библиотеку намного выше быстрого ADO и всех прочих поделок на эту тему :)
Внимание, вопрос (любопытства ради, не призыв к холивару): а что тебе не нравится в DbSimple?
Внимание, вопрос (любопытства ради, не призыв к холивару): а что тебе не нравится в DbSimple?
Просто плохой велосипед.
Лучше бы взяли что-нибудь постандартнее. PEAR там покапайте или ещё где. Просто если вам доведётся работать в команде, то ваш чудо-велосипед могут не оценить коллеги. Или того хуже — у них могут быть свои. Проверенные временем сторонние библиотеки очень помогают в некоторой стандартизации. Если бы всем было лень учить чужое и не лень изобретать своё, то сидели бы мы сейчас на деревьях с миллионами разнообразных палок-копалок. Зато у каждого своя.
В целом ваш скрипт просто не приносит видимой мне пользы. По поводу нескольких серверов — можно было бы и ассоциативным массивом проблему решить. Не говоря уже о том, что по хорошему надо выносить данные о подключении в файл конфигов и один раз кинув свой такой файл на каждый сервак благополучно забыть обо всех проблемах.
По поводу получения данных в виде массива. Лучше не надо, если действительно не надо. В 90% случаев приходится работать с записями последовательно. Если опустить подробности и вариации, то в большинстве случаев MySQL сервер отвечает вам «кусками». Т.е. PHP гораздо быстрее получит доступ к первым строчкам в случае большой выборки. И вместо того чтобы тормозить до того момента как все данные придут можно было бы начать их обрабатывать. Ну уж про память я и не говорю. Если выборка большая, то в памяти будет болтаться здоровенный массив. Традиционно проблему решают так: создают методы next и fetchAll. Первый будет просто дёргать mysql_fetch_array для вашего ресурса каждый раз, т.е. позволит начать работу не дожидаясь прихода всех данных. Второй позволит получить массив, если действительно нужен массив. Собственно вы его и написали.
Ещё раз настоятельно рекомендую покопать чужой код. Там часто бывают умные и интересные мысли.
Лучше бы взяли что-нибудь постандартнее. PEAR там покапайте или ещё где. Просто если вам доведётся работать в команде, то ваш чудо-велосипед могут не оценить коллеги. Или того хуже — у них могут быть свои. Проверенные временем сторонние библиотеки очень помогают в некоторой стандартизации. Если бы всем было лень учить чужое и не лень изобретать своё, то сидели бы мы сейчас на деревьях с миллионами разнообразных палок-копалок. Зато у каждого своя.
В целом ваш скрипт просто не приносит видимой мне пользы. По поводу нескольких серверов — можно было бы и ассоциативным массивом проблему решить. Не говоря уже о том, что по хорошему надо выносить данные о подключении в файл конфигов и один раз кинув свой такой файл на каждый сервак благополучно забыть обо всех проблемах.
По поводу получения данных в виде массива. Лучше не надо, если действительно не надо. В 90% случаев приходится работать с записями последовательно. Если опустить подробности и вариации, то в большинстве случаев MySQL сервер отвечает вам «кусками». Т.е. PHP гораздо быстрее получит доступ к первым строчкам в случае большой выборки. И вместо того чтобы тормозить до того момента как все данные придут можно было бы начать их обрабатывать. Ну уж про память я и не говорю. Если выборка большая, то в памяти будет болтаться здоровенный массив. Традиционно проблему решают так: создают методы next и fetchAll. Первый будет просто дёргать mysql_fetch_array для вашего ресурса каждый раз, т.е. позволит начать работу не дожидаясь прихода всех данных. Второй позволит получить массив, если действительно нужен массив. Собственно вы его и написали.
Ещё раз настоятельно рекомендую покопать чужой код. Там часто бывают умные и интересные мысли.
согласен, согласен! насчет того, чтобы хранить такие данные, как пароли к хосту (!) внутри класса — довольно бредовая мысль. зачем было тогда вообще создавать такой класс? каждый раз править код класса при переносе с сервера на сервер? признаться, написал свой первый комментарий, даже не вглядываясь особо в код. присмотревшись, был обескуражен…
Название «очередной модуль...» как бы намекает
>> но зачастую приходит_ь_ся использовать
У вас ошибка. там не нужен мягкий знак. проверяется вопросом «что делает? — приходится»
У вас ошибка. там не нужен мягкий знак. проверяется вопросом «что делает? — приходится»
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Очередной модуль для работы с MySQL