| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > Vingrad CMS > Класс для работы с базой |
| Автор: Wowa 17.6.2005, 14:35 | ||
В принципе, можно написать свой класс, но есть уже готовый и довольно хороший. А писать самому - будет примерно тоже самое. Давайте этот класс возьмем за основку для работы с базой.
Или будут еще какие-либо предложения у кого-то? |
| Автор: Mal Hack 17.6.2005, 17:49 | ||
|
| Автор: Irokez 17.6.2005, 19:24 | ||||
для работы с базой:
для работы с таблицей:
|
| Автор: Рыжий 17.6.2005, 20:49 |
| хм, в книге ПРоффесиональное PHP программирование давалось class db - простой API для работы с базой данных, чем он плох?? |
| Автор: Irokez 17.6.2005, 20:53 | ||
тем что мы его не видели |
| Автор: Рыжий 17.6.2005, 22:49 | ||
Я вообщето его с книги наьирал, поэтому могут быть синтаксические ошибки
|
| Автор: Mal Hack 17.6.2005, 22:57 |
| PHP-Script Этот класс имхо не даст той универсальности. ИМХО, слишком прост. |
| Автор: Рыжий 18.6.2005, 00:03 |
| Mal Hack Будь проще и к тебе потянутся а почему ты считаешь что нужно извращаться?? (просто вопрос для себя...) |
| Автор: Gold Dragon 18.6.2005, 10:53 |
| а правда, чем плох этот простой класс? Mal Hack, твой вариант что-то слишком навороченный (но может он и лучше |
| Автор: Wowa 18.6.2005, 11:37 |
| Мне нравится мой вариант |
| Автор: Рыжий 18.6.2005, 12:04 |
| Ну вот, начинается лебедь рак и щука - каждый в свою сторону... |
| Автор: Opik 18.6.2005, 14:12 |
| Думаю класс не нужен, ибо будем ориентироваться на развитие PHP? А в такой штуке как PHP 5.1 есть другая штука - PDO http://ee.php.net/pdo |
| Автор: Wowa 18.6.2005, 14:27 | ||
Очень хорошо, но пока это вещь сырая - думаю нужен собственный класс. Методы можно назвать также. Чтобы в будущем при необходимости подменить одно - другим не составило труда. |
| Автор: Opik 18.6.2005, 14:31 |
| Wowa Я думаю лучше сразу писать на эту вещь, хоть и сыроватую..А потом, если она сгинет (тьфу тьфу тьфу) то написать аналогичный класс. |
| Автор: Wowa 18.6.2005, 15:40 | ||
Для этого надо всем ставить новейшую версию ПХП. А если будут найдены баги, то снова ПХП обновлять. Обновление ПХП на веб-серверах - частенько не так легко и быстро, как кажется. |
| Автор: Opik 18.6.2005, 15:42 |
| Wowa к кому времени как мы закончим писать... будет намного стабильнее - я уверен. |
| Автор: Wowa 18.6.2005, 15:44 | ||
Но на данный момент - вещь сырая. И с ней имхо лучше не работать. Аргументируй плиз, свое желание работать с PDO. Что такое даст нам PDO, чего не даст нам свой класс? Добавлено @ 15:47 Впрочем, я согласен, что PDO очень заманчиво выглядит. |
| Автор: Opik 18.6.2005, 15:52 | ||
1) Простота - не нужно писать свои драйвера - просто подключил и подредактировал конструктор 2) быстродейсвие Да тут много интересного читайте сами: http://ee.php.net/pdo |
| Автор: Sardar 18.6.2005, 17:04 |
| Согласен с Opik, ваши классы это просто перевызов функций MySQL, т.е. конкретная имплементация драйвера БД. А те кро работал не только с MySQL знают что разработчики БД часто плевать хотели на стандарты и для каждой БД иногда требуеться чуть чуть подправить SQL запрос. PDO уже имеет несколько драйверов, а не один под MySQL |
| Автор: Рыжий 18.6.2005, 17:31 |
| Если писать актуальную cms - могу согласиться с opik'ом - действительно нужно использовать САМЫЕ последние технологии, но все же не отрицаю что PDO - не на 100% рабочем уровне |
| Автор: Wowa 18.6.2005, 17:51 | ||
Остается только надеятся, что очень много изменено не будет. Добавлено @ 17:55 Получается, что нам надо будет ставить PHP 5.1.0 Beta 1 и с ним работать. Я не люблю работать с бета-версиями продуктов. |
| Автор: Рыжий 18.6.2005, 18:15 | ||
Тогда в итоге у нас получится PDO |
| Автор: Medved 18.6.2005, 19:12 |
| А мне кажется, что надо создать один абстрактный класс для работы с БД. Который и будет использоваться при написании всего приложения. А методы для работы с каждой конкретной БД подлючать в виде "картриджей". Проще говоря можно будет использользовать непосредственно несколько различных БД для хранения данных (MySQL, PostgreSQL, MSSQL, ORACLE (!) что очень важно для более менее-крупных заказчиков, и т.д.). При установке пользователь сам будет указывать какую БД использовать, и настраивать коннект. Это будет "фишкой" этого продукты, и соответсвенно увеличивает его конкурентноспособность. Затрат на это много не потребуется, просто необходимо грамотно продумать объектную модель приложения. Тут конечно лучше всего было бы этот реализовать через интерфейсы, но в PHP они насколько я понимаю не поддерживаются. А жаль Да и приложение будет проще сопровождать при таком подходе. (вообще, проекты такого уровня, я рекомендовал бы писать на Java, вся мощь IT в твоих руках, PHP имхо слишком слаб для проектов такого уровня, и что самое главное - небезопасен) |
| Автор: Рыжий 18.6.2005, 19:21 |
| Стоп а разве PDO не работает со всеми базами?? |
| Автор: Medved 18.6.2005, 19:27 | ||
Я не рекомендовал бы использовать PDO. Во первых - оно эксперементальное, а во вторых если в чем-нибудь будет затор, мы не сможем что-либо изменить, и в итоге будем стоять на одном месте. ИЛи придется все переписывать, или вести долгую переписку с авторами расширения. Я уже сталкивался с такими случаями. |
| Автор: Opik 19.6.2005, 00:59 | ||
кой какие интерфайсы есть в пятерке. |
| Автор: IZ@TOP 20.6.2005, 19:59 | ||||
| Я конечно понимаю на счет того почему стоит использовать PDO, но для начала стоит задуматься для кого и для чего мы пишем нашу CMS? Смогут ли те люди которые будут ее потом использовать найти все те "самые современные" технологии и тем самым обеспечить работоспособность всей системы в целом. Вот над чем стоит действительно задуматься. Хотя с другой стороны вполне возможно если мы будем писать эту систему пол года/год, тогда вполне возможно большинство тех новх технологий, задествованных в данном проекте будут уже доступны большинству. По теме: если будем делать свой класс для работы с БД, в нем неплохо было бы использовать SQL шаблоны, чтобы не мучиться с обработкой передаваемых данных. Т.е. к примеру у нас есть такой SQL шаблон:
А выполнение SQL запроса будет выглядеть примерно следующим образом:
Как наверное всем стало ясно, %{number type} заменяется на переменную под номером number форматиоуемую согласно типу type. Что явно позволит избежать не только SQL инъекций. |
| Автор: Opik 20.6.2005, 22:40 | ||
IZ@TOP
PHP 5.1 Обновляется каждые 4 часа, сиё значит что баги всё таки фиксятся, что не может не радовать. Можно даже устроить сотрудничество, с каким нить хостом. |
| Автор: IZ@TOP 20.6.2005, 22:45 | ||
К примеру с Euorohoster.net? |
| Автор: Рыжий 20.6.2005, 22:54 | ||
Лучше имхо использовать САМЫЕ новые технологии и самые новые разработки. Проэкт мы ведь делаем на будущее а не на прошлое |
| Автор: Mal Hack 20.6.2005, 22:56 | ||
| IZ@TOP а ты уверен что все СУБД воспримут ANCI'99 на 100% Добавлено @ 22:57
Нельзя так делать, т.к. нет уверенности что эти техгнологии приживуться.. Надо использовать то, что уже хоть как-то юзается |
| Автор: Wowa 20.6.2005, 22:59 | ||
Конечно можно. |
| Автор: Рыжий 20.6.2005, 23:39 |
| Mal Hack Конечно же технологии всегда нужно использовать в меру, но все таки баналные php5 xml+xsl+xslt - это просто обязанность. А мы должны шагнуть еще дальше и перепюнуть все (ведь мы этого хотим?) |
| Автор: IZ@TOP 20.6.2005, 23:39 | ||
| С хостингом мы уже решили. Добавлено @ 23:40
переплюнуть то конечно можно, но здесь по большей части стоит вопрос в рациональности. |
| Автор: Gold Dragon 21.6.2005, 09:03 | ||
Шагать лучше не дальше, а вногу. Так что создавать CMS на современных тенденциях не гуманно, а вдруг стандарты не пойдут дальше развиваться или так и остануться не востребованными. Да и срок их внедрения очень примерный |
| Автор: Рыжий 21.6.2005, 10:30 |
| Red Dragon Тогда шагаем в ногу! |
| Автор: IZ@TOP 21.6.2005, 13:54 |
| Ну если уж на то пошло, то можно использовать такие технологии как XForms. Очень классная штука кстати, правда широкого распространения пока не получила, но АВТОВАЗ уже применяет ее в своих корпоративных решениях. |
| Автор: Opik 21.6.2005, 14:23 |
| Везде подвели итоги вроде, подведем и тут. PDO имхо самое лучше по производительности и в меру с развитием технологий. |
| Автор: Opik 22.6.2005, 12:57 |
| PDO можно ставить и на 5.0.4 так что решено - PDO |
| Автор: DemoCode 29.11.2005, 20:29 | ||||||
Для этих целей, я обычно пользуюсь классом adodb - очень удобный ИМХО. Вот ссылка: http://adodb.sourceforge.net/#download
Меня не разу не подводил этот класс. Может и вам пригодится. |
| Автор: dm9 1.6.2006, 16:26 |
| Я понимаю, что тема старая, но вставлю всё же своё мнение - может, кого натолкнёт на умные мысли. Единственный реально продуманный класс для работы с БД, который я видел - PEAR'овский. Он тяжёлый, конечно, но никто не заставляет использовать именно его - можно взять оттуда часть идей и реализовать их самостоятельно. Все вышеперечисленные классы (включая PDO) не содержат всего того, что реально часто используется и может быть сокращёно с вызова двух-трёх методов до одного. Например, это mixed GetValue(string $query) - выбирает первую ячейку первого столбца. mixed GetRow(string $query) - выбирает первую строку. boolean RowExists(string $query) - смотрит, выдаёт ли запрос хотя бы одну строку. Мелочи, но насколько они могут облегчить жизнь... |
| Автор: Opik 3.6.2006, 00:39 |
| dm9, string PDOStatement::fetchColumn ( [int column_number] ) Returns a single column from the next row of a result set. PDOStatement::nextRowset -- Advances to the next rowset in a multi-rowset statement handle Это насчет PDO. Который меня устраивает на все 100. |
| Автор: m1m1n0 9.7.2006, 02:30 | ||
Меня тоже устраивало, но не нашел аналога метода mysql_num_rows Если есть такой, подскажите плз... |
| Автор: Vaulter 21.7.2006, 15:18 | ||
| давайте начнем сначала, какой должен быть класс? я так вижу ситуацию, что необходим список функций с четкими аргументами (в смысле.. задокументированными), на котором (списке) будут формироватся уровень и так __construct (?) connect (выбирать сразу БД?) selectRow($tablename, $tail); selectCell(%tablename,$query); selectList($tablename,$query);// выбирает сразу в массив query($query);//основная фун-я запроса, возврат и все дела с сохранением всякой лабуды, типа ошибок, русурса, или кол-ва записей....... хотя. нах fetch() fetchCell() к примеру free() report - вот приблуда:
Добавлено @ 15:19 собственно... тут ктонить есть? |
| Автор: Sardar 21.7.2006, 15:31 |
Vaulter, а зачем это всё? Есть PEAR:DB, Adodb для PHP4/5 и PDO для PHP5. Свой слой абстракции это лишнее, ИМХО. |
| Автор: Vaulter 21.7.2006, 17:17 |
| Sardar, а хз! а если нету? adodb - жуткая штука PEAR:DB - посмотрим... PDO - иногда и нету. |
| Автор: Wowa 2.9.2006, 00:30 |
| Итак, я склоняюсь к PDO. Opik, твое мнение относительно PDO не поменялось? |
| Автор: Opik 2.9.2006, 16:44 |
| Wowa, нет, полностью его поддерживаю и пропагандирую |
| Автор: Wowa 2.9.2006, 17:04 |
| Opik, значит решили. Используем PDO. |
| Автор: IZ@TOP 5.9.2006, 14:16 |
| Wowa, будем писать тулзы для удобного формирования SQL запросов? Типа строитель множественных вставок, апдейтов и удаления? |
| Автор: Opik 5.9.2006, 15:48 |
| IZ@TOP, Мне кажется это лишнее. |
| Автор: Opik 5.9.2006, 18:38 |
| Wowa, Такой отрывок кода специфичен для определенных модулей и выносить такое в драйвер я считаю лишним. |
| Автор: Wowa 5.9.2006, 18:43 | ||
конечно. В драйвер это выносить не стоит. |
| Автор: IZ@TOP 6.9.2006, 10:32 | ||||||
| Ребята! Вы меня по моему не совсем правильно поняли! Допустим, мы имеем массив из формы:
Нам нужно внести эту запись в базу. Как же мы поступим? Напишем код вручную:
Или же исполним один простой метод - конструктор SQL запросов:
И это в простейшем случае. Может ведь статься что вставок или апдейтов за раз нужно сделать множество для одной табоицы. И будем дублировать много кода, прогоняя в цикле к примеру составление SQL'я? А можно ведь обойтись вызовом всего одного метода! |
| Автор: Wowa 6.9.2006, 10:44 |
| IZ@TOP, мне кажется. что довольно редко надо производить вставку того, что пришло без изменений.. или же без какого-то доп. поля. |
| Автор: Opik 6.9.2006, 11:08 | ||||||
| IZ@TOP, Это как раз в тему о MVC. Но на примере твоего кода, твой "идеал":
вместо:
Как видишь, никакого
здесь нет, другое дело если меняется структура и её нужно везде менять, это да, но для этого я и предложил MVC паттерн. |
| Автор: IZ@TOP 6.9.2006, 12:04 | ||
В смысле? А как на счет конструктора условий? Я думаю что это очень полезная вещь. Ладно, я то в либы добавлю, а там уж кому как, а я буду использовать) Добавлено @ 12:07 Opik, Не забывай, намного быстрее сделать множественную вставку, нежели делать их 30 раз подряд. В любом случае, мне кажется что несколько удобнее, и я бы еще даже добавил: сокращает время на отладку SQL запросов, так как конструктор не способен забыть вставить скобку, кавычку или запятую. |
| Автор: Wowa 6.9.2006, 12:12 | ||
имхо очень редко множественные ставки нам нужны будут. |
| Автор: Opik 6.9.2006, 12:18 | ||
IZ@TOP,
Ммм, поясни? |
| Автор: IZ@TOP 6.9.2006, 12:39 | ||||
Вполне возможно что я незнаю всех возможностей PDO, но:
В данном случае происходит вставки раз за разом выполняя запрос. Есть множественные вставки, которые представляют из себя VALUES через запятую:
Должен сказать что это работает гораздо быстрее. И как я уже сказал, на уровне конструктора мы сокращаем время на просмотр SQL ошибок которые появляются из-за опечаток в коде. Добавлено @ 12:40 Я опять цитирую "и я бы еще даже добавил: сокращает время на отладку SQL запросов, так как конструктор не способен забыть вставить скобку, кавычку или запятую." |
| Автор: Opik 6.9.2006, 12:41 |
| А я что то различия не нашел, между моим кодом и твоим, разве что у тебя в цикле, у меня последовательно, тем более у тебя ошибка |
| Автор: IZ@TOP 6.9.2006, 13:11 |
| Opik, это пример а не ошибка. Это и есть экономия на отклике базы при отправке пакетов. У тебя будут каждый раз отправляться а у меня один раз и сама вставка будет быстрее. |
| Автор: Opik 6.9.2006, 13:14 | ||||
| IZ@TOP, Объясни мне в чем отличие:
от
В плане последовательности и скорости вставки? |
| Автор: IZ@TOP 6.9.2006, 16:20 | ||||||
Opik,
Это я писал пример с PDO. А разница с твоим примером в том, что $array1, $array2 тон плохого кода - это раз, а если ты не знаешь сколько записей тебе нужно вставить, что и имелось ввиду в данном случае, то естественно цикл. Если же использовать конструктор, мы за один запрос вставляем все пришедшие к нам записи! Прям разжевывать все нужно! Ей богу! Opik, ты знаешь чем отличаются вставки
и
? |
| Автор: Opik 6.9.2006, 17:26 | ||
| IZ@TOP, Я понял, что ты имел в виду, знаю. Но я не понимаю где отличие (в этом плане) в этих 2-ух кусках кода? И давай не будем про тон плохого кода, как я тебе уже писал, твой код тоже никуда не годиться
констуктор? |
| Автор: Wowa 6.9.2006, 18:03 |
| Спор на пустом месте. Я считаю, что необходимость вставки в одну таблицу нескольких строк - это довольно редкая задача и задача эта будет вряд ли где-то в ядре системы. (ну разве, что создание бэкапа базы и восстановление). |
| Автор: IZ@TOP 6.9.2006, 18:31 | ||
| Wowa, уверяю что в административной панели при работе с модулями будет очень много необходимости делать множественные вставки! И это не спор))) Он просто издевается, притворяясь маленьким несмышленым мальчиком
У меня вообще кода не было кроме того что с PDO. Внимание вопрос: Что быстрее, один запрос к базе данных или 30? |
| Автор: Wowa 6.9.2006, 18:35 | ||
Несколько примеров - в студию! |
| Автор: IZ@TOP 6.9.2006, 18:39 | ||
| Wowa, голосование, тесты, привязка к разделам, привязка типов, жанров и т.п. Достаточно или продолжить? ЗЫ я щас работая над проектом типа афиши, там этого добра ой-ой-ой сколько. И кстате, почему
На этот момент вообще у всех ноль внимания? |
| Автор: Opik 6.9.2006, 19:35 |
никогда не считал пропущенную запятую большой ошибкой, все правиться за пару секунд так реч то не об этом. |
| Автор: Wowa 6.9.2006, 21:36 | ||
лично я даже запятую пропускаю крайне редко, поэтому это и не аргумент для меня. |
| Автор: Sardar 7.9.2006, 00:03 | ||
Млин, а как же обернуть всё это в логику, что бы не сразу со странички формы в базу, а что то подобное:
Прикол в том что такие классы очень просты, сами устроены по принципу http://pear.php.net/package/DB_DataObject, расшаривают общий код, но пользовать их одно удовольствие потом Нет прямой связи с БД, захотели сделать откат, не меняя публичный API сделали. P.S. это я к тому что на слое абстракции PEAR: DB/PDO народ сразу логику ставит, делая прямые запросы... тоже можно, но ИМХО не красиво. |
| Автор: Wowa 7.9.2006, 10:05 | ||
неа, недостаточно. Во всех перечисленных тобою вещах множественную вставку - редко где придется делать, да и не будет она большой(ну самый максимум 20 строк) и выполняться будет крайне редко. Поэтому тут совершенно очевидно, что должен использоваться тот код, который более понятен потом при разборке будет, тот код - который удобнее разработчику писать. |
| Автор: IZ@TOP 7.9.2006, 10:12 |
Речь как раз об этом! Sardar, как раз об этом я и говорю! Хотя в чистом виде DataObjects я бы использовать не стал, именно тот что PEAR - ибо тормоз, а вот что-то вроде твоего варианта вполне может подойти. Но далее уже с разных точек нужно рассмотреть что к чему. |
| Автор: IZ@TOP 7.9.2006, 11:12 | ||
Хорошо - возьмем программы передач/афишу. Сколько вставок делается за один раз при импорте данных? Лучше 10 раз по 100 чем 1000 раз подряд. По моему действительно глупый спор. Я пытаюсь об оптимизации разработки и уменьшении затрачиваемых ресурсов сервера говорить. По моему на это все же стоит обратить внимание. Добавлено @ 11:17 И еще мне кажется что использовании метадологии DataObjects приведет к тому что добавление одного поля в базе и инпута в шаблон это все что нужно будет сделать для модификации компонента/модуля. |
| Автор: IZ@TOP 22.9.2006, 13:22 |
| http://forum.vingrad.ru/index.php?act=ST&f=178&t=113059&st=0#entry863339 |
| Автор: Alone 17.10.2006, 11:45 |
| Ребята, я думаю, Вам надо почитать про ORM. Это спасет отца русской демократии... |
| Автор: Wowa 21.10.2006, 17:09 |
Ты имеешь ввиду http://en.wikipedia.org/wiki/Object-relational_mapping. Зачем нам объектные базы данных? Кто и что думает по этому поводу? Мне кажется, что не нужно. |
| Автор: Semenov 23.10.2006, 08:53 |
| Я не вижу смысла в orm. Мое мнение - не нужно. |
| Автор: korchasa 18.7.2007, 10:30 | ||
Сразу после этой фразы можно прекращать разработку. Так как наличие большого объема запросов к данным (пусть даже в виде DBAL) приведет к "костности" системы. |
| Автор: imm 13.10.2007, 22:27 |
| А уже хоть что-нибудь готово, или вы все спорите? |
| Автор: SlikJay 24.4.2008, 20:12 |
| http://dklab.ru/lib/DbSimple/ http://dklab.ru/lib/DbSimple/manual.html |
| Автор: DeamonShan 29.4.2008, 14:27 |
| Предлагаю использовать классы от форума PHPBB очень неплохие классы, у них почти под все БД есть классы... синтаксис один а БД можно использовать любую.. MSSQL, MySQL, PosgreSQL итд итп... |
| Автор: awers 14.2.2009, 16:02 | ||
Немного работы над ошибками провести и юзать сие:
Одно точно - юзать стоит именно mysqli. И сторонние либы нафиг нафиг. |
| Автор: Wowa 14.2.2009, 16:28 | ||
можешь пояснить почему? |
| Автор: awers 14.2.2009, 16:52 |
| быстро, современно, никаких mysql_real_escape_string и пр. Добавлено через 4 минуты и 16 секунд На счёт стабильности - я на этом классе за прошлый год три с половиной десятка сайтов запустип. Нареканий пока никаких. Жизнеспособно ) |
| Автор: IZ@TOP 27.2.2009, 16:06 | ||
Ну, как бы escape_string там тоже есть. На счет работоспособности - обкатано на продакшене высоконагруженного проекта. Однако, сам класс mysqli все равно прикрыт оболочкой и моделькой. Напрямую никогда не используется. |