ОО подход к тривиальной проблеме

[.des.]

в php 4 нельзя

Note: In PHP 4, only constant initializers for var variables are allowed. To initialize variables with non-constant values, you need an initialization function which is called automatically when an object is being constructed from the class. Such a function is called a constructor.

http://www.php.net/manual/en/language.oop.php#keyword.class

 

[vitus]

Автор оригинала: camka
Почему то мне казалось что так поступать нельзя. Инициализация атрибутов являющихся объектами классов должно выполнятся в конструкторе.
Опровергни.

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

 

[sokol]

Автор оригинала: Vasya
IMHO, в листинге продуктов тебе нужны vendor_name & vendor_id
поэтому вынимаешь их джойном и суешь в продукт. А если юзер ткнет на имя вендора и захочет посмотреть на расширеную инфу по вендору., тогда и надо вынимать всю инфу по вендору. То бишь, в любом случае, в товаре должна быть ССЫЛКА на вендора, а не весь вендор.

Вот-вот Васек правильно!
Самое интересное, то что люди продолжают извращаться и придумывать никому не нужную навороченность.
Запомните! Классы нужно писать тогда, когда они могут пригодиться в любом другом проекте.

Читайте проектирование БД, при корректном проектировании все решается одним SQL запросом! Используйте CASE-системы для корректного проектирования баз данных, и не надо заниматься ерундой. Такие штуки неплохи лишь для тренировки, но никак не в реальных проектах...

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

А что если на такой скрипт Яндекс нападет? Сервант рухнет...

 

[vitus]

Автор оригинала: sokol
Классы нужно писать тогда, когда они могут пригодиться в любом другом проекте.

не совсем так, классы хороши, когда у тебя сложная предметная область. Потом если следовать дальше по этому пути, то можно и от функций отказаться , - самый правильный язык - ассемблер!

Такие штуки неплохи лишь для тренировки, но никак не в реальных проектах...

Я согласен, что SQL - рулез, аднак в реальных проектах не всегда и всё можно запхать в чиста-реляционную модель
а уж проектировать базу, чтобы ВСЁ РЕШИТЬ одним запросом, да ещё и на мойскле - тоже извращение - почище приведённых выше.

фичи надо использовать там где это
(НАДО && ВОЗМОЖНО)==true.

А что если на такой скрипт Яндекс нападет? Сервант рухнет...

с чего бы это ему рухать ?

 

[sokol]

с чего бы это ему рухать ?

Ну если мне не почудилось, то в первом посте camka хотела использовать запросы в цикле. Или я не прав? Ну а если Яндекс нападет на этот сайт, то ему надо будет хотя бы раз просмотреть содержимое всех страниц, т.е. запросов полетит к базе с туеву хучу...., нельзя ж так издеваться над бедным сервером "Ну и запросы у вас!"- сказала база и повисла
Вот тут можно почитать про это:
http://www.nordnet.ru/talk/forum.php3?opt=listtopic&forumid=10&postid=429

http://www.nordnet.ru/talk/forum.php3?opt=listtopic&forumid=10&postid=434

Я согласен, что SQL - рулез, аднак в реальных проектах не всегда и всё можно запхать в чиста-реляционную модель
а уж проектировать базу, чтобы ВСЁ РЕШИТЬ одним запросом, да ещё и на мойскле - тоже извращение - почище приведённых выше.

Это называется не извращение, а серьезная работа... Вот скажите кто нибудь из программистов PHP пользуется CASE средствами? Или ты считаешь это лишним?
Советую почитать книжечку "Бзы данных - модели, разработка, реализация", может после этого мнение переменится, как переменилось мое когда-то

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

Данную задачу я бы решил с PEAR, SQL и без единой ф-ии
Правда для PEAR у меня есть собственная замена она еще маленькая, но растет потихоньку по мере надобности...
Единственнй разумный ответ дал юзер по имени vasya, только никто его не послушал

 

[vitus]

Ну если мне не почудилось, то в первом посте camka хотела использовать запросы в цикле. Или я не прав?

как раз не хотел - потому и тред родился

Это называется не извращение, а серьезная работа...

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

кто нибудь из программистов PHP пользуется CASE средствами? Или ты считаешь это лишним?

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

Данную задачу я бы решил с PEAR, SQL и без единой ф-ии

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

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

Единственнй разумный ответ дал юзер по имени vasya, только никто его не послушал

кроме одного , да и тот не расслышал

 

[sokol]

как раз не хотел - потому и тред родился

Ну в его случае задача проста :

$product = new Product(); 
$vendor  = new Vendor(); 

$sql_stat =  "

SELECT $product->tablename.prod, $vendor->tablename. vend
FROM $product->tablename, $vendor->tablename
WHERE  $product->tablename.vend_id = $vendor->tablename.id
ORDER BY $order
LIMIT $offset, $quantity

";

while($row = mysql_fetch_array(mysql_query($sql_stat)))
         {
                 echo $row['prod']."|".$row['vend'];
          }

Можно и в его терминах, но vendor_id обязательно длжен присутствовать в таблице товаров, это обязательное условие корректности данной схемы БД.

С PEAR вообще ф-ий PHP не видно

А вообще можно делать так получить объединенное отношение tovartable.vendor_id - vendor.id, а потом сортировать его как угодно, выбирать, фильтровать, группировать и.т.д
SQL вот все что нужно.... и никаких надуманных классов не надо абсолютно.

А не подскажешь что за задача? По моему она поставлена конкретно, вывести Продукт - Поставщик

Можно и join, но я обычно делаю так