Перейти к содержимому

Фото
- - - - -

ORM на PHP кто делал?


  • Вы не можете создать новую тему
  • Please log in to reply
40 ответов в этой теме

#1 Setor

Setor
  • Постоялец
  • 1 890 сообщений
  • Откуда:Эстония, Таллин

Отправлено 26 мая 2007 - 11:15

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

Штука чертовски удобная, очень полезная на сайтах с кучей всяких SQL запросов, т.к. большинство запросов - однотипные и когда делаешь копи-пасте с одного места в другое, а потом добавляешь различные условия, например,
if ( ! is_logged() ) $query .= ' AND `private` = 0';
, потом приходится делать проверки, а было ли что-то в условии WHERE и т.д. Можно конечно выработать стратегию, которая чуть упростит эти проверки, но всё равно налицо тотальное дублирование кода, чего очень следует избегать. Вот тут и родилась идея написать свою небольшую реализацию ORM.

Но тут возникает сложность, на простых запросах всё работает шоколадно, но когда в дело идут join'ы логика усложняется и приходится извращаться.

Вот пример как это работает:
// Объект запроса
$query = new Query();

// Инициализируем таблицы, которые будут использованы в запросе
$P  = new Table( 'products', 'P' ); // P будет алиасом таблицы products FROM `products` AS P
$PP = new Table( 'products_pictures', 'PP' );

// Указываем поля, которые будут извлечены в ходе запроса
$P->select(); // Будут извлечены все поля SELECT P.*
$PP->select( 'pictures_name' );

// Добавляем в запрос таблицы
$query->join( $P ); // FROM `products` AS P

// Таблица добавляется методом LEFT JOIN, возвращается объект типа Критерий
// для задания критерия LEFT JOIN'а в секции ON ( ... )
$PP_criteria = $query->leftJoin( $PP ); // LEFT JOIN `products_pictures` ON ...

// Позже планируется добавить конструкцию USING ( ... )
$PP_criteria->andCondition( $P->field( 'pictures_id' ), $PP->field( 'pictures_id' ), '=' ); // ON ( P.`pictures_id` = PP.`pictures_id` )

// Добавляем условие в блок WHERE P.`categories_id` = 123
$query->andCondition( $P->field( 'categories_id' ), 123 ); // по-дефолту знак =

Получается такой запрос:
SELECT P.*, PP.pictures_name
FROM products P
LEFT JOIN products_pictures ON ( P.pictures_id = PP.pictures_id )
WHERE P.categories_id = 123

Если надо добавить сложные условия, то инициализируем объект типа Condition и добавляем в него простые условия (заменим этим кодом последнее условие)
$conditions = new Condition();
$conditions->andCondition( $P->field( 'categories_id' ), 123 );
$conditions->orCondition( $P->field( 'categories_id' ), 456 );

// в итоге получится условие ( P.categories_id = 123 OR P.categories_id = 456 )

// После чего добавим его к условиям в наш селект
$query->andConditions( $conditions );

Получается такой запрос:
SELECT P.*, PP.pictures_name
FROM products P
LEFT JOIN products_pictures ON ( P.pictures_id = PP.pictures_id )
WHERE ( P.categories_id = 123 OR P.categories_id = 456 )

Таким же образом добавляются в конец запроса группировки, ORDER BY, лимиты

С первого взгляда кажется громоздко, но довольно удобная штука... Реализаций море, но мне так показалось более удобно... На данный момент используются 3 класса Query, Condition и Table

Вот ещё одна интересная реализация на PHP5 http://www.mzz.ru/do...html#db.queries
  • 0

#2 Vladson

Vladson

    XTGamers.com

  • Постоялец
  • 1 921 сообщений
  • Откуда:Эстония, Таллинн

Отправлено 26 мая 2007 - 17:11

Нафига изобретать велосипед ?

Таких по всему интернету написано и каждый считает что у него лучше

ИМХО на самом деле если программиста надо избавлять от

написания SQL запросов

то лучше либо избавится от такого программиста
  • 0
Один Владсон может за...ать всех, кроме себя самого. Два Владсона могли бы за...ать абсолютно кого угодно, но Владсон единственный и неповторимый. ©Vladson

Вы либо способны перелопатить тонны информации и отсеять лишнее, либо программистом не будете. ©Psih

Не вазелин, а бизнес-гель ©Avagraen

#3 crazy russian

crazy russian
  • Пользователь
  • 153 сообщений

Отправлено 26 мая 2007 - 20:50

Setor, то, что ты написал, это обычный SQL builder, а не ORM. Тем не менее, чем тебя готовые O/R mapping не устраивают? Тот же Propel?

то лучше либо избавится от такого программиста

В чем логика, не пойму?

Сообщение изменено: crazy russian (26 мая 2007 - 23:16 )

  • 0

#4 Setor

Setor
  • Постоялец
  • 1 890 сообщений
  • Откуда:Эстония, Таллин

Отправлено 27 мая 2007 - 00:51

Нафига изобретать велосипед ?

Таких по всему интернету написано и каждый считает что у него лучше

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

Vladson, подобные комментарии лучше пиши тем начинающим, которые внаглую просят написать за них скрипт и требуют, чтобы он работал как надо. Насколько мне известно, на PHP нет какой-то общепризнанной толковой ОРМ, так же нету стандарта де-факто или паттерна. Просто каждый делает сам как ему удобно. Моей целью было охватить так же PHP4, хоть и пишу я только на PHP5, но есть некоторые товарищи ради которых по коммерческим соображениям приходится до сих пор возиться с 4кой.

ИМХО на самом деле если программиста надо избавлять от
написания SQL запросов то лучше либо избавится от такого программиста

Я тоже не понял, что ты тут имел ввиду, но зачем понимать всё буквально? Программист пишет тот же запрос, только другим способом. У меня есть настолько сложные запросы в приложениях, что волосы дыбом встают (примера привести не могу, т.к. это часть закрытых коммерческих систем). Я уже сделал несколько довольно сложных запросов на своём творении и в целом оно работает отлично. Можно в принципе, прикрутить ещё и кеш запросов, но в целом и без кеша на производительности использование подобной системы практически не сказывается (на обычных интернет-сайтах без серьёзной нагрузки).

Setor, то, что ты написал, это обычный SQL builder, а не ORM. Тем не менее, чем тебя готовые O/R mapping не устраивают? Тот же Propel?

Вот, нормальный комментарий. Готовые реализации настлько громоздки, что их невозможно использовать в малых проектах. У меня средний сайт весит без картинок с шаблонами в районе 1Мб порядка 150 файлов, тот же Propel - 200 файлов и 1.5Мб, клиенты не поймут :) Мы тут набросали небольшую ООП CMF, которую можно использовать на различного рода небольших сайтах и я решил сделать SQL Builder, чтобы облегчить написание SQL запросов с кучей логики в моделях приложения (MVC), т.к. большинство запросов в различных модулях очень схожи и просто лень их копировать, изменять, добавлять новые условия. А при успешном внедрении буду использовать и в более крупных приложениях.

Сейчас у меня есть только сомнения, как лучше задавать условия запроса (секция WHERE), текущая реализация работает, но от неё отдаёт неприятным душком ;)) (как пишет М. Фаулер в своей книжке по Рефакторингу)

Я наверное плохо выразился в первом посте, т.к. пытался донести до всех

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

Я хотел сказать, что это далеко не ОРМ, а система, которая служит для написания SQL запросов. И в конец надо было добавить "написания SQL запросов в явном виде". Просто не знал как лучше назвать.

P.S. вообще целью данной темы так же являлось узнать, сколько человек на форуме на серьёзном уровне владеют PHP и в целом аспектами веб-программирования. Пока что я насчитал 3х, включая себя.

Сообщение изменено: Setor (27 мая 2007 - 01:04 )

  • 0

#5 crazy russian

crazy russian
  • Пользователь
  • 153 сообщений

Отправлено 27 мая 2007 - 18:10

А почему бы не упростить этот builder? Честно говоря, использовать этот API кажется сложнее, чем написать обычный SQL. Основная проблема ведь, как я понял, это то, запросы однотипные, а вот условия фильтрации везде разные. Зачем для этого вводить кучу новых объектов и создавать такой builder, где вообще не нужно знать SQL, но при этом сам API подразумевает это знание..

Предлагаю что-то вроде:
$query = new Query("SELECT P.*, PP.pictures_name FROM products P LEFT JOIN products_pictures ON ( P.pictures_id = PP.pictures_id ))");
$query.addEquals("P.category_id", 123); 
$query.addEquals("P.id", $filterObjectFromView.getProductId()); 
// в методе addEquals помимо добавления в SQL - заодно проверяешь, 
// а передали ли вообще этот параметр, нужно ли его добавлять в запрос,
// передали правильные значения? Имеет ли доступ залогиненый 
// пользователь к этим данным? И так далее.
// можно добавить еще один метод a la
// addInnerJoin("P.product_id", "xxx.id", "select * from xxx")
echo $query.getSQL();

  • 0

#6 zedirtybastard

zedirtybastard
  • Пользователь
  • 499 сообщений

Отправлено 27 мая 2007 - 19:49

Как выше уже было сказано, это не O/R M маппер, глянь, как например сделано в Hibernate, и я, если честно, не могу сказать, что использование мапперов всегда оправдано, мы по крайней мере отказались от их использования.
Слушай, а ты не думал использовать прокси-классы? Я реализовывал их недавно на шарпе, на РНР это будет немного сложнее, ибо в нем нет рефлекшна, но тем не менее, имхо это интересный подход, когда класс имеет в себе методы для сохранения самого себя в базу и имеет возможность заполнить все свои property самостоятельно.
  • 0

#7 Setor

Setor
  • Постоялец
  • 1 890 сообщений
  • Откуда:Эстония, Таллин

Отправлено 27 мая 2007 - 21:23

А почему бы не упростить этот builder? Честно говоря, использовать этот API кажется сложнее, чем написать обычный SQL. Основная проблема ведь, как я понял, это то, запросы однотипные, а вот условия фильтрации везде разные. Зачем для этого вводить кучу новых объектов и создавать такой builder, где вообще не нужно знать SQL, но при этом сам API подразумевает это знание..

Ты прав, не на каждом запросе использование подобного API будет оправдано. Просто не всегда запросы являются статическими, задумка была такова, чтобы автоматически их генерировать в зависимости от разных условий. Идеальным примером были бы запросы на получение списка продуктов магазина. Например, нужно получить список продуктов из корзины, список продуктов из какого-то заказа, список продуктов с какой-то категории, список продуктов без картинок или с картинками и т.д. По сути, запрос на получение списка продуктов всегда один, но в каждом случае дополнительно могут джойниться разные таблицы и добавляться новые условия, писать по запросу для каждого случая очень утомительно, особенно утомительно вносить в них изменения, вот тут подобный builder был бы очень кстати.

Предлагаю что-то вроде:

$query = new Query("SELECT P.*, PP.pictures_name FROM products P LEFT JOIN products_pictures ON ( P.pictures_id = PP.pictures_id ))");
$query.addEquals("P.category_id", 123); 
$query.addEquals("P.id", $filterObjectFromView.getProductId()); 
// в методе addEquals помимо добавления в SQL - заодно проверяешь, 
// а передали ли вообще этот параметр, нужно ли его добавлять в запрос,
// передали правильные значения? Имеет ли доступ залогиненый 
// пользователь к этим данным? И так далее.
// можно добавить еще один метод a la
// addInnerJoin("P.product_id", "xxx.id", "select * from xxx")
echo $query.getSQL();

Вот это уже интересный вариант, я сначала примерно так и хотел сделать: написать основную часть запроса и в конце навешивать условия, но как показала практика, такой подход оправдан лишь на простых запросах, которые у меня к несчастью появляются очень редко. Но учесть данный подход думаю, стоит.
  • 0

#8 Setor

Setor
  • Постоялец
  • 1 890 сообщений
  • Откуда:Эстония, Таллин

Отправлено 27 мая 2007 - 21:49

Как выше уже было сказано, это не O/R M маппер, глянь, как например сделано в Hibernate, и я, если честно, не могу сказать, что использование мапперов всегда оправдано, мы по крайней мере отказались от их использования.
Слушай, а ты не думал использовать прокси-классы? Я реализовывал их недавно на шарпе, на РНР это будет немного сложнее, ибо в нем нет рефлекшна, но тем не менее, имхо это интересный подход, когда класс имеет в себе методы для сохранения самого себя в базу и имеет возможность заполнить все свои property самостоятельно.

Ты сейчас говоришь про ORM, мы же определились, что всётаки речь шла о простом SQL Builder'е. Hibernate - это уже слишком круто, PHP - это не Java ;) Я пока что не вижу смысла сохранять состояние объектов в БД. В PHP5 есть рефлекшен, я его изучал, штука очень интересная, не могу сравнить его возможности с рефлекшеном в Ява, т.к. не работал с последней, но ты порой инфу - я думаю, очень реально получить полное состояние объекта в ПХП. Вопрос в том, где это использовать?

P.S. думаю, есть смысл переименовать тему...

И продолжая тему хотелось добавить, что большинство однотипных запросов используется в админках различных модулей сайта, я стараюсь максимально упростить создание админок для новых модулей. В этом мне главным образом помогают API валидации форм, API вывода различного рода таблиц (пример можно увидеть в Bitrix5) и сейчас я пришёл к выводу, что очень нужно API для унифицированного создания запросов.
  • 0

#9 zedirtybastard

zedirtybastard
  • Пользователь
  • 499 сообщений

Отправлено 27 мая 2007 - 22:08

1) рефлекшн лично я использую для того, чтобы получить список всех fields в обьекте и автоматического их загона в базу данных, ну там в ADO.NET немного по другому реализована работа с базой. Смысл в том, что нет нужды теперь рыться в коде, для добавления нового поля просто добавляешь field и он уже синхронизируется с базой.

2) может тебе перейти на другую базу? :) в MS SQL и Оракл можно используя процедуры и функции реализовать значительно большую гибкость, чем в MySQL, да и триггеры очень прикольная штука.
  • 0

#10 Setor

Setor
  • Постоялец
  • 1 890 сообщений
  • Откуда:Эстония, Таллин

Отправлено 27 мая 2007 - 22:29

1) рефлекшн лично я использую для того, чтобы получить список всех fields в обьекте и автоматического их загона в базу данных, ну там в ADO.NET немного по другому реализована работа с базой. Смысл в том, что нет нужды теперь рыться в коде, для добавления нового поля просто добавляешь field и он уже синхронизируется с базой.

Это всё очень интересно, но реально я пока не знаю где это можно применить. Наверное, надо почитать как и зачем это едят ;) Список свойств объекта в PHP можно получить и без рефлекшена, т.к. последний предоставляет намного большие возможности.

2) может тебе перейти на другую базу? в MS SQL и Оракл можно используя процедуры и функции реализовать значительно большую гибкость, чем в MySQL, да и триггеры очень прикольная штука

В MySQL 5 тоже есть такие возможности, но ты пойми, что не каждый клиент сможет купить Оракл) Да и ресурсы для него нужны какие... Мы ещё не вышли на такой уровень ;) Хранимые процедуры - это конечно, мощно - у меня есть несколько мест, где они бы очень пригодились, аналогичная ситуация и с триггерами, но увы, MySQL 4.1 - то, на чём приходится работать в 90% случаев.
  • 0

#11 BlackIce

BlackIce

    грозный Дон Пако

  • Пользователь
  • 313 сообщений
  • Откуда:Tallinn

Отправлено 28 мая 2007 - 09:26

Люди, вы можете мне обьяснить чем плоха такая вещь
function dbQuerySelect($rows,$table,$query,$perPage,$curPage){
$sql->query="SELECT  ".(($rows <>'')? $rows:"*")." FROM ".$table." ".(($query <>'')? "WHERE ".$query:"")." ".(($defLimit <>'')? "LIMIT ".$defLimit.",".$perPage."":"")." ") or die("DIE:: SELECT ".(($rows <>'')? $rows:"*")." FROM ".$table." ".(($query <>'')? "WHERE ".$query:"")." ".(($defLimit <>'')? "LIMIT ".$defLimit.",".$perPage."":"")." "
}

это упрощенный вариант и все же ...
можно делать все так же как и описано выше, только помоему меньне гемора ... ?
или я что-то пропустил?
  • 0
а кули, я тоже рульный дизайнер ввв.ме2.ее

#12 zedirtybastard

zedirtybastard
  • Пользователь
  • 499 сообщений

Отправлено 28 мая 2007 - 09:53

Люди, вы можете мне обьяснить чем плоха такая вещь

function dbQuerySelect($rows,$table,$query,$perPage,$curPage){
$sql->query="SELECT  ".(($rows <>'')? $rows:"*")." FROM ".$table." ".(($query <>'')? "WHERE ".$query:"")." ".(($defLimit <>'')? "LIMIT ".$defLimit.",".$perPage."":"")." ") or die("DIE:: SELECT ".(($rows <>'')? $rows:"*")." FROM ".$table." ".(($query <>'')? "WHERE ".$query:"")." ".(($defLimit <>'')? "LIMIT ".$defLimit.",".$perPage."":"")." "
}

это упрощенный вариант и все же ...
можно делать все так же как и описано выше, только помоему меньне гемора ... ?
или я что-то пропустил?


А ссылка на соединение у тебя где?
Я лично считаю, что в РНР изначально правильно реализована работа с базой, т.е. на уровне ядра четко виден баланс между упрощением кода и гибкостью.
Мапперы и билдеры - это все от лукавого :)
  • 0

#13 BlackIce

BlackIce

    грозный Дон Пако

  • Пользователь
  • 313 сообщений
  • Откуда:Tallinn

Отправлено 28 мая 2007 - 10:12

zedirtybastard, она раньше определена была) я же написал, что упрощенный код)не буду же я все классны и прочее выкладывать сюда ... )))
  • 0
а кули, я тоже рульный дизайнер ввв.ме2.ее

#14 Setor

Setor
  • Постоялец
  • 1 890 сообщений
  • Откуда:Эстония, Таллин

Отправлено 29 мая 2007 - 00:49

Люди, вы можете мне обьяснить чем плоха такая вещь

function dbQuerySelect($rows,$table,$query,$perPage,$curPage){
$sql->query="SELECT  ".(($rows <>'')? $rows:"*")." FROM ".$table." ".(($query <>'')? "WHERE ".$query:"")." ".(($defLimit <>'')? "LIMIT ".$defLimit.",".$perPage."":"")." ") or die("DIE:: SELECT ".(($rows <>'')? $rows:"*")." FROM ".$table." ".(($query <>'')? "WHERE ".$query:"")." ".(($defLimit <>'')? "LIMIT ".$defLimit.",".$perPage."":"")." "
}

это упрощенный вариант и все же ...
можно делать все так же как и описано выше, только помоему меньне гемора ... ?
или я что-то пропустил?

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

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

#15 CiDRoN

CiDRoN

    Конструктивизм на форум.ее

  • Админ
  • 8 434 сообщений
  • Откуда:Tallinn

Отправлено 29 мая 2007 - 02:08

я лично, если пишу движки, sql отдельно классифицирую основные запросы на отдельные функции тож, а потом уже минимум добавляешь при составлении запроса. правда, немного теряешь скорости при обработке, зато максимально просто в написании.
  • 0
Закон суров, но это закон. Читайте правила.

#16 Vladson

Vladson

    XTGamers.com

  • Постоялец
  • 1 921 сообщений
  • Откуда:Эстония, Таллинн

Отправлено 29 мая 2007 - 02:29

подобные комментарии лучше пиши тем начинающим

Не переходи на личности (это первый признак отсутствия аргументов) лучше просто ответь на один простой вопрос: "зачем ты изобрёл велосипед с квадратными колёсами, когда велосипедов с круглыми колёсами уже изобретено полно и они бесплатны ?"

Если бы ты разработал движок блога или гостевухи на крайняк я бы ещё понял (99% опен-сорс движков оставляют желать лучшего, есть только очень редкие исключения достойные внимания типа "wordpress" и.т.д.) но таких вот конструкторов и так дофига и больше, да они ещё и отличного качества.

Т.е ИМХО (а я высказываю в этом топике только ИМХО и никого не пытаюсь оскорбить или под;%:ать) ты просто потратил зря время, лучше бы пива выпил с друзьями...

Что касается конкретно критики твоей реализации то тут я бессилен, я пользовался не многими вариантами таких "велосипедов" по этому не особо много с чем могу сравнивать, возможно он и не плох, но я не могу поручиться за это (как в прочем и за обратное)
  • 0
Один Владсон может за...ать всех, кроме себя самого. Два Владсона могли бы за...ать абсолютно кого угодно, но Владсон единственный и неповторимый. ©Vladson

Вы либо способны перелопатить тонны информации и отсеять лишнее, либо программистом не будете. ©Psih

Не вазелин, а бизнес-гель ©Avagraen

#17 Fors

Fors
  • Пользователь
  • 328 сообщений

Отправлено 29 мая 2007 - 08:26

ОРМ на пхп? самолично? уже после этого тему в юмор.
а еще понравились готичные комментарии на албанском %) код тоже так пишете? или только на форуме такие комменты.

По теме: зачем изобретать велосипед? неужели нет нормальных фреймворков для поставленных целей?

Как выше уже было сказано, это не O/R M маппер, глянь, как например сделано в Hibernate, и я, если честно, не могу сказать, что использование мапперов всегда оправдано, мы по крайней мере отказались от их использования.Слушай, а ты не думал использовать прокси-классы? Я реализовывал их недавно на шарпе, на РНР это будет немного сложнее, ибо в нем нет рефлекшна, но тем не менее, имхо это интересный подход, когда класс имеет в себе методы для сохранения самого себя в базу и имеет возможность заполнить все свои property самостоятельно.

а я не могу представить себе систему, которая больше 2х таблиц и 3 селектов, которая потеряла бы что-то от отказа от Хибернейт :(.
По поводу того, что класс должен сам себя сохранять - я считаю, что тут тогда будет смешение дата слоя и слоя бизнес логики, но все ИМХО.
  • 0

#18 BlackIce

BlackIce

    грозный Дон Пако

  • Пользователь
  • 313 сообщений
  • Откуда:Tallinn

Отправлено 29 мая 2007 - 09:02

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

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


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

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

$this->dbQuerySelect('','cms_gallery LEFT JOIN cms_gallerypictures ON cms_gallerypictures.parentID=cms_gallery.ID',"cms_gallery.ID=1",'','');

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

разницы между
$blablabla->dobavitjPole('field1') для join и т.д. ... и тем что например я написал нету особой,
хотя может я чегото не понимаю, тогда искренне надеюсь, что мне популярно обьяснят, нужны ли эти мапперы и для чего?

Сообщение изменено: BlackIce (29 мая 2007 - 09:06 )

  • 0
а кули, я тоже рульный дизайнер ввв.ме2.ее

#19 Vladson

Vladson

    XTGamers.com

  • Постоялец
  • 1 921 сообщений
  • Откуда:Эстония, Таллинн

Отправлено 29 мая 2007 - 09:34

хотя может я чегото не понимаю

Если так то нас двое уже :)
  • 0
Один Владсон может за...ать всех, кроме себя самого. Два Владсона могли бы за...ать абсолютно кого угодно, но Владсон единственный и неповторимый. ©Vladson

Вы либо способны перелопатить тонны информации и отсеять лишнее, либо программистом не будете. ©Psih

Не вазелин, а бизнес-гель ©Avagraen

#20 BlackIce

BlackIce

    грозный Дон Пако

  • Пользователь
  • 313 сообщений
  • Откуда:Tallinn

Отправлено 29 мая 2007 - 09:35

Vladson, :D я думаю таких тут большинство ...
  • 0
а кули, я тоже рульный дизайнер ввв.ме2.ее

#21 Vladson

Vladson

    XTGamers.com

  • Постоялец
  • 1 921 сообщений
  • Откуда:Эстония, Таллинн

Отправлено 29 мая 2007 - 09:37

Конечно возможно в редких случаях это и помогло бы добиться чего нибудь хорошего, (например позволило бы написать СМS который можно устанавливать на кучу разных СУБД) но ИМХО в 99% случаев это лишнее так как нагруженные проекты наоборот отпимизируются под максимальное быстродействие и там такие "велосипеды" будут только мешать, а большенству мелких достаточно MySQL.
  • 0
Один Владсон может за...ать всех, кроме себя самого. Два Владсона могли бы за...ать абсолютно кого угодно, но Владсон единственный и неповторимый. ©Vladson

Вы либо способны перелопатить тонны информации и отсеять лишнее, либо программистом не будете. ©Psih

Не вазелин, а бизнес-гель ©Avagraen

#22 BlackIce

BlackIce

    грозный Дон Пако

  • Пользователь
  • 313 сообщений
  • Откуда:Tallinn

Отправлено 29 мая 2007 - 09:53

Vladson, спасибо за инфо, но помоему тогда ADODB самое оптимальное ...
  • 0
а кули, я тоже рульный дизайнер ввв.ме2.ее

#23 Vladson

Vladson

    XTGamers.com

  • Постоялец
  • 1 921 сообщений
  • Откуда:Эстония, Таллинн

Отправлено 29 мая 2007 - 10:19

BlackIce, аналогов полно, среди них есть на все цвета и вкусы, почему я и считаю что ТС

просто потратил зря время


  • 0
Один Владсон может за...ать всех, кроме себя самого. Два Владсона могли бы за...ать абсолютно кого угодно, но Владсон единственный и неповторимый. ©Vladson

Вы либо способны перелопатить тонны информации и отсеять лишнее, либо программистом не будете. ©Psih

Не вазелин, а бизнес-гель ©Avagraen

#24 zedirtybastard

zedirtybastard
  • Пользователь
  • 499 сообщений

Отправлено 29 мая 2007 - 10:23

а я не могу представить себе систему, которая больше 2х таблиц и 3 селектов, которая потеряла бы что-то от отказа от Хибернейт :(.

Я не до конца понял, что ты хочешь в конечном итоге сказать? Выиграет или проиграет?
Я не могу точно тебе сказать, касательно Hibernate, ибо я пробовал его порт по шарп, NHibernate.
Штука удобная, но:
1) Ее надо изучать, рыться по форумам и в документации, которая (по-моему) оставляет желать лучшего
2) Когда смотришь в sql профайлере, что он там творит, начинаешь думать, что мог бы реализовать и лучше
3) С mysql он по идее должен работать нормально, но для MS SQL он сыроват, почти не поддерживает Stored Procedures, а для нас это очень важно

По поводу того, что класс должен сам себя сохранять - я считаю, что тут тогда будет смешение дата слоя и слоя бизнес логики, но все ИМХО.

Смотря какую модель ты используешь, если MVC, то да, она изначально подразумевает 3 слоя, если N-Tier лепи их сколько хочешь и выдумывай сам.
  • 0

#25 BlackIce

BlackIce

    грозный Дон Пако

  • Пользователь
  • 313 сообщений
  • Откуда:Tallinn

Отправлено 29 мая 2007 - 10:27

zedirtybastard, спасибо, стал умнее :)
  • 0
а кули, я тоже рульный дизайнер ввв.ме2.ее

#26 Setor

Setor
  • Постоялец
  • 1 890 сообщений
  • Откуда:Эстония, Таллин

Отправлено 29 мая 2007 - 19:26

Спасибо за комментарии, я понял, что зря все эти годы программировал на PHP :)

С некоторыми комментариями я согласен, с некоторыми - нет. Более подробно далее...
  • 0

#27 Setor

Setor
  • Постоялец
  • 1 890 сообщений
  • Откуда:Эстония, Таллин

Отправлено 29 мая 2007 - 19:40

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

Это "немного" многократно окупается в ходе поддержки проекта, по этому не стоит экономить на спичках.

Не переходи на личности (это первый признак отсутствия аргументов) лучше просто ответь на один простой вопрос: "зачем ты изобрёл велосипед с квадратными колёсами, когда велосипедов с круглыми колёсами уже изобретено полно и они бесплатны ?"

Если бы ты разработал движок блога или гостевухи на крайняк я бы ещё понял (99% опен-сорс движков оставляют желать лучшего, есть только очень редкие исключения достойные внимания типа "wordpress" и.т.д.) но таких вот конструкторов и так дофига и больше, да они ещё и отличного качества.

Т.е ИМХО (а я высказываю в этом топике только ИМХО и никого не пытаюсь оскорбить или под;%:ать) ты просто потратил зря время, лучше бы пива выпил с друзьями...

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

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

Vladson, спасибо за инфо, но помоему тогда ADODB самое оптимальное ...

ADODB хорошая штука, но слишком здоровая. У меня средняя страница с 30ю незакешированными (на стороне сервера) инклудами генерится за меньшее время, чем выполняется 1 запрос в таком гиганте или генерится из кеша 1 страница SMARTY. Я всегда ищу оптимальное решение.

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

$this->dbQuerySelect('','cms_gallery LEFT JOIN cms_gallerypictures ON cms_gallerypictures.parentID=cms_gallery.ID',"cms_gallery.ID=1",'','');

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

разницы между
$blablabla->dobavitjPole('field1') для join и т.д. ... и тем что например я написал нету особой,
хотя может я чегото не понимаю, тогда искренне надеюсь, что мне популярно обьяснят, нужны ли эти мапперы и для чего?

Объясняю, ты привёл функцию, которая лишь производит конкантенацию строк, остальное ты пишешь сам. Можно передать некоторые аргументы массивами, я так тоже делаю, но чтобы построить ряд условий, опять надо делать проверки и выйдут те же яйца, только в профиль.

Конечно возможно в редких случаях это и помогло бы добиться чего нибудь хорошего, (например позволило бы написать СМS который можно устанавливать на кучу разных СУБД) но ИМХО в 99% случаев это лишнее так как нагруженные проекты наоборот отпимизируются под максимальное быстродействие и там такие "велосипеды" будут только мешать, а большенству мелких достаточно MySQL.

Хорошо звучит, в реальности мы понимаем, дальше MySQL не уйти.
  • 0

#28 Setor

Setor
  • Постоялец
  • 1 890 сообщений
  • Откуда:Эстония, Таллин

Отправлено 29 мая 2007 - 20:03

Я думаю, мы не будем тут трогать сильно нагруженные проекты, речь идёт об обычных сайтах с одной лишь особенностью - максимально короткие сроки разработки и дальнейшая поддержка без особых геморов. К примеру, был один проект, в нём была куча разбросанных по файлам схожих запросов, нужно было сделать изменения в БД, пришлось перелопатить несколько файлов. Положил всё в одно место, но сделал 3 метода, которые работают с разными группами схожих запросов, различия лишь в джойнах. Снова потребовалось внести небольшие изменения - изменил 3 метода, если бы всё было в 1м классе, реализующем различные типы данного запроса, без какого либо повторения кода, я бы съэкономил много времени, а теперь представим, что в приложении есть и другие схожие запросы, мы их так же кладём в класс и я думаю, может получиться ситуация с дублированием кода в 2х классах, после чего мы их приводим к единому интерфейсу. Вот что мне нужно и всем тем, кто экономит своё время.

Люди часто пишут mysql_query( ... ) or die( ... ); Я не понимаю, почему не выделить вызов этой функции в отдельный метод, который бы так же отвечал за вывод ошибок. Есть 1 аргумент в пользу 1го случая - использовать нечто вроде __FILE__ __LINE__, но ни кто не запрещает пропарсить результат ф-ции debug_backtrace() - и мы ничего не теряем...

ОРМ на пхп? самолично? уже после этого тему в юмор.
а еще понравились готичные комментарии на албанском %) код тоже так пишете? или только на форуме такие комменты.

По теме: зачем изобретать велосипед? неужели нет нормальных фреймворков для поставленных целей?
а я не могу представить себе систему, которая больше 2х таблиц и 3 селектов, которая потеряла бы что-то от отказа от Хибернейт :(.
По поводу того, что класс должен сам себя сохранять - я считаю, что тут тогда будет смешение дата слоя и слоя бизнес логики, но все ИМХО.

По поводу ОРМ мы уже определились, я ошибся в определениях. Комментарии конечно для форума, иначе ни кто читать даже не стал бы ;) Правда, и с комментариями не каждый осилит приведённый пример. Насчёт албанского - не понял. Я бы не стал сравнивать ПХП с языками более низкого уровня, по этому чем богаты, тем и сыты!
  • 0

#29 Vladson

Vladson

    XTGamers.com

  • Постоялец
  • 1 921 сообщений
  • Откуда:Эстония, Таллинн

Отправлено 29 мая 2007 - 20:06

Ты первый начал и не в первый раз.

Я не начал, я просто непонимаю зачем это нужно.

чтобы максимально приблизиться к идеалу

А какой он должен быть этот идеал ?

Для быстродействия вообще все эти танцы не нужны (только мешают) для гибкости (под разные СУБД) придётся "забить" на скорость и как результат не возможно будет использовать.

Я не знаю зачем это нужно, я считаю что в любом продукте ключевое значение имеет простота (как кода так и логики в целом) потому что чем проще код тем меньше шансов что в нём будут ошибки (или даже дыры)

Мне кажется если и писать что-то подобное то на Си, потому что РНР сам по себе довольно тормознутый (не вообще, а по сравнению с Си)
  • 0
Один Владсон может за...ать всех, кроме себя самого. Два Владсона могли бы за...ать абсолютно кого угодно, но Владсон единственный и неповторимый. ©Vladson

Вы либо способны перелопатить тонны информации и отсеять лишнее, либо программистом не будете. ©Psih

Не вазелин, а бизнес-гель ©Avagraen

#30 Setor

Setor
  • Постоялец
  • 1 890 сообщений
  • Откуда:Эстония, Таллин

Отправлено 29 мая 2007 - 22:53

Для быстродействия вообще все эти танцы не нужны (только мешают) для гибкости (под разные СУБД) придётся "забить" на скорость и как результат не возможно будет использовать.

Быстродействие - это такая штука... одно только соединение с БД выполняется дольше, чем создание 100 объектов. Самый большой тормоз на сегодня - это жёсткий диск, т.е. все дисковые операции сосут по полной, кеширование опткода исключает все издержки на загрузку и компиляцию файлов. Я 2 раза подумаю, следует ли добавлять в проект лишний файл, чем создавать ли лишний объект. А так, это проблемы сервера и хостинга - хоть 100 файлов инклудь) А вызов какой-то функции, метода - это такая мелочь, которую можно заметить может на очень загруженных ресурсах, но если там делается упор на максимальную производительность в ущерб удобности, то тут всё наоборот, можно пренебречь сотой секунды на удобные обёртки, чем тратить в последствии часы на поиск ошибок и добавление новых возможностей.

Если думать о потребляемой приложением памяти, то следует обратить внимание в первую очередь на апаче + медленные клиенты. 1 процесс апача отжирает от 20 до 40 мб оперативки - это ничто по сравнению с моей программой, которая ест не более 4мб в самых сложных ситуациях!
  • 0