По точности механические часы (коими являются почти все топовые модели известных брендов) довольно сильно уступают кварцевым. Механика в часах это скорее дань традициям (ибо ручная работа и т.п.), но никак не точность.
Данные будут записаны в базу данных автоматически.
Т.е. при данном подходе (без явного вызова чего-либо типа save()) изменение любого атрибута ведет к sql-запросу? Если мне нужно изменить у объекта значения двух атрибутов, то это будет реализовано двумя sql-запросами?
В данном случае до вызова $asus->data = $i; объект $i является полумертвым, т.к. не имеет родителя, хотя по структуре БД должен его имееть. Существует мнение (и, имхо, небезосновательное), что конструктор должен создавать только полноценные (с проинициализированными всеми необходимыми полями) объекты. ИМХО, правильнее было бы так:
На самом деле, базе данных становится не очень хорошо от слишком большого количества загруженных хранимых процедур
Интересно, на чем основано данное утверждение?
Вообще почти все доводы автора по поводу снижения производительности системы при использовании ХП для меня звучат не очень убедительно. ИМХО перенос бизнес-логики ближе к данным как раз увеличивает производительность системы снижая расходы на передачу промежуточных данных и их преобразования из объектной модели в реляционную и обратно.
На php и без goto написаны тонны говнокода неопытными программистами. А если придется копаться в говнокоде то, имхо, разницы уже не будет с goto он написан или без.
А если в страничку вставить фрейм с адресом другого сайта, то из этого фрейма можно будет делать ajax-запросы к этому сайты, а потом прокидывать данные в основной документ.
По точности механические часы (коими являются почти все топовые модели известных брендов) довольно сильно уступают кварцевым. Механика в часах это скорее дань традициям (ибо ручная работа и т.п.), но никак не точность.
Вы хотели сказать Nikon D3 и Nikon D700, ведь правда? Ибо в D300 кропнутая матрица
Если вы о мегапикселях, то в этот список попадают: Canon 1Ds Mark III, 5D Mark II и Nikon D3x
Т.е. при данном подходе (без явного вызова чего-либо типа save()) изменение любого атрибута ведет к sql-запросу? Если мне нужно изменить у объекта значения двух атрибутов, то это будет реализовано двумя sql-запросами?
В данном случае до вызова $asus->data = $i; объект $i является полумертвым, т.к. не имеет родителя, хотя по структуре БД должен его имееть. Существует мнение (и, имхо, небезосновательное), что конструктор должен создавать только полноценные (с проинициализированными всеми необходимыми полями) объекты. ИМХО, правильнее было бы так:
$i = $asus->newItem();
$i->name = ‘Asus M51VR-AP157C’;
$i->cost = 415;
$i->quantity = 210;
А как же российские бюро кредитных историй? Например, ОБКИ, НБКИ и т.п.
Ну так для этого и были добавлены Java в Oracle, Tcl, Python, Perl в PostgreSQL и т.д.
Интересно, на чем основано данное утверждение?
Вообще почти все доводы автора по поводу снижения производительности системы при использовании ХП для меня звучат не очень убедительно. ИМХО перенос бизнес-логики ближе к данным как раз увеличивает производительность системы снижая расходы на передачу промежуточных данных и их преобразования из объектной модели в реляционную и обратно.
А как же Selenium Eclipse?