Как стать автором
Обновить

Комментарии 45

Отформатируйте, пожалуйста.
Видимо в этот момент автор топика всё ещё исправлял статью. :)
Имхо ActiveRecord намного удобнее
использую AdoDB или SimpleDB и не знаю проблем
Я конечно рад за вас с ActiveRecord,AdoDB или SimpleDB. Но это все ORM, задача которого нивелировать разницу в БД-х, а не повысить читабельность программы.
Почитайте прос симлп дб
http://dklab.ru/lib/DbSimple/
один из пунктов идеологии гласит: Библиотека не должна выравнивать различия между разными СУБД на уровне языка SQL.
Я был не прав по поводу DbSimple, автоматом перечислив в ряду с другими. Это не ОРМ и предлагает она ту же концепцию, что и я. Естественно глубже и с ООП, и т.п.
Действительно??? Нет, вы правда в этом уверенны? Просто... я наверное хочу признатся, что у меня, к великому моему сожалению, вышел неправильный ActiveRerod, давайте я вам приведу небольшой пример, что бы вы сами поняли
$user = new User();
$user['username'] = 'root';
$user['password'] = 'qwerty';
$user->usergroup['name'] = 'admins group!';
var_dump($user['usergroup'], $user->usergroup);

$user->save();
на что собственна в бд получим:
user(id, username, password, usergroup, email):
1231, root, md5(qwerty), 91231, root@thishost.com

а в Usergroup(id, name):
91231, admins group!

в браузере увидим что-то вроде
int 123

object(Usergroup)[2]
protected 'properties' => array(...)


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

Попробуйте в процедурном стиле поработать с десятками связанных сущностей, которые разбросанны по нескольким источникам данных. Думаю что через три часа мучений вы первый побежите набрасывать два слоя абстракций модели данных и еще орм сверху.
Я совсем не против слоев абстракции. Просто каждому овощу свое время.
Если я был не понят с идеей статьи, то это моя вина. Плохо изложил. А народ пока пусть хоть chop()у порадуется.
А вы вообще знаете что такое ORM? AdoDB или SimpleDB - это не ORM. ORM расшифровывается Object-relational mapping. Технология носит такое название, поскольку позволяет поставить соответсвие между реляционной БД и объектами домена вашего приложения (это совершенно необходимо при использовании модели предметной области). Это, как раз для улучшения кода в первую очередь и нужно. Вы просто попробуйте попользоваться такой системой для php: Doctrine, например, или Zend_Db_Table. Вы сразу почувствуете преимущества.
А можно поинтересоватся, где тут облегчение мне жизни? То, что я теперь буду работать с голыми данными из базы, но используя другую функцию, если раньше мы писали так
$result = mysql_query("SELECT * FROM users");
$users = array();
while ( $row=mysql_fetch_array($result) ) {
  // много кода, в котором мы что-то делаем с row, к примеру
}
то сейчас мы будем писать так что-ли:
foreach(sql_get_rows("SELECT * FROM users") as $row) {
  // абсолютно тот же код.
}

Люди, наверное не зря придумали такие вещи как Абстракция бд, модель данных, activerecord, datamapper.

Когда же вы научитесь учится сами, прежде чем учить чему-то других...
Если вы знате и умеете пользоваться такими словами, как Абстракция бд, модель данных, activerecord, datamapper, то эта статья не для вас. Правда непонятно, почему вы не видите огромной разницы в тех двух кусках, что вы привели. Первый кусок невозможно корректно вписать в MVC, а второй - без проблем.
Очень, очень хочется посмотреть на то, как второй кусок кода будет вписан в mvc(в народе: разделим наше приложение на шаблонизатор, самописный класс\функции для работой с бд, и будем их дергать в контроллере, кидая в шаблонизатор).

Почему же не вижу, вижу, в первом кусе я забыл убрать $users = array(), а во втором foreach появился ;)

И действительно, эта статья очень поможет начинающим программистам, дав понять, как не стоит писать, даже если "очень очень" хочется.
То, какие данные достаютса из базы решается в модели, а как отображаются - во View. В вашем куске это не разделяемо в принципе.
Кстати:

$rows = array();
while ($row = mysql_fetch_object($res)) {
$rows[] = $row;
}

Можно заменить одной красивой строчкой:

for ($rows = array(); $row = mysql_fetch_object($res); $rows[] = $row);

И ещё: нашёл красивый способ убрать последнюю занятую:

$str = "one, two, ";
$str = chop($str, ", ");

Оно какбэ почти звучит как предложение: «отрезать запятую в конце».
> for ($rows = array(); $row = mysql_fetch_object($res); $rows[] = $row);

Образец того, за что надо бить линейкой по рукам.
А ваш код, наверное, образец, с которого нужно писать стандарты кодирования ;)
Простите, за что?
Потому же, почему в академическом примере чередования 1 и 2 в цикле нельзя делать как 3-$i.
Но пример уважаемого посмотреть профиль mr_stupid даже соответствует тому, что вы пропагандируете:

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

Почему же нужно бить линейкой по рукам?
Вы же понимаете, что эти слова означают повышение читабельности программы, а не чисто количественное ее сжатие во чтобы ни стало. Уважемый mr_stupid понизил читабельность.
Смею предположить что на C/C++ вы никогда не писали. А очень зря, ибо пример mr_stupid-а очень нагляден и очевиден.

кидайте вы это php, и учитесь нормальным языкам.
Для справки: за 20 лет программистского стажа писать на всякихх приходилось. И сейчас пишу не только на PHP. А вот статью про PHP написал. Не возражаете?
Для справки: за 15 лет программистского стажа писал на многих языках.

Легче относитесь к критике, и не считайте что вас окружают одни школьники.

Статья ваша безусловно полезная, но только для совсем-совсем начинающих (я бы ещё только добавил метод quote, по аналогии с перловой DBI), а аудитория хабра, к счастью, состоит из более-менее профессионалов, по-этому такая масса негативных откликов.

И вообще, надо радоваться.
за chop() спасибо, не знал о таком финте))
это не финт, а алиас rtrim, она еще с 4-й версии имеет необязательный параметр со списком символов.
$s = rtrim($s, "\r\n");
А за меня зендфреймворк думает.
Ваш sql_set не оптимален, т.к. к примеру он берет в скобки системные функции например md5(), NOW() и прочие.
print sql_set(array("name" => 'disc', 'pass'=>"md5('disc')"));
Я пишу выше именно про SQL функции, пример с мд5 возможно не удачен, просто первое что скопипастил :), можете представить там NOW() :)
Вы знаете, не было проблем. Иногда пишется:
"UPDATE table set `time`=NOW() WHERE id=$id"

а иногда так:
$fields['password']=md5($fields['password']);
$fields['time']=time();
sql_set($fields);
надеюсь, $id не напрямую из $_GET/$_POST берется.
Если было бы напрямую, стояло бы WHERE id={$_GET[id]}. Но и потом нельзя же в эту тему и безопасность впихивать. Слишком сложно будет.
Помоему на каждый "чих" создавать функцию это лишнее. + Код без вот этих ваших ф-й лично мне был бы понятнее, а так возможно придется рыскать по файлам и искать какую либо из них и разбиратся чтоже она и как делает.
Статья неплохо подойдёт тем кто только начал изучать php, она — хороший пример перехода на чуть более высокий уровень программирования (оторваться от низкоуровневых, встроеных, php функций, использовать свои более высокоуровневые). Следующим шагом неплохо было бы почитать про асбтракцию в бд, объектную модель, ORM, чего советую и автору.
Ужасно :( Стоит использовать как наглядное пособие на тему "Как не стоит прогрессировать в программировании на PHP".
> Под выским уровнем понимается достижение цели при минимальном и быстро получаемом коде (количества строк кода, символов в строке) [...] Если разработчик вместо 30 строк кода пишет только 10, то верятность ошибки снижется в три раза.

Это точно не так.
Чтобы сделать код простым, часто делают как раз наоборот.
Сравните (простите за С в этом топике, я не знаю конкретно PHP, но думаю, что смысл сохранится на любом языке):

int x1=getSomeX()+10;
int y1=getSomeY(1)*2+5;
int x2=x1*2+20;
int y2=getSomeY(2)*2+5;
int c=func3(x1,y1,x2,y2);


и

int x=getSomeX();
int c=func3(x+10,getSomeY(1)*2+5,x*2+30,getSomeY(2)*2+5);
// а представьте, что у этой функции 10 параметров


Где легче ошибиться? Что труднее отлаживать?

С многоэтажными вызовами WinAPI я могу привести тонну таких примеров, когда запись в строчку хуже и порождает ошибки, просто наверно это неуместно в этом топике.

Попробуйте взять любой (не написанный специально для этого случая) кусок кода в 30 строк и сжать в 10. Будет нечитабельный для постороннего ужас.

Я-то как раз сторонник писать в 10 строк вместо 30 - часто красивее, но читабельности не добавляет (в отличие от ошибок, если быть невнимательным или переборщить с лаконичностью).

> Дальнейшее сопровождение и модификации более короткого кода тоже несомненно требует гораздо меньшего времени и человеческих ресурсов.

Вот это - наверно мой любимый кусок кода (спёрто из какой-то книги):
y-=x++;
Это лаконично и красиво, но тот, кто будет сопровождать и модифицировать, будет долго вспоминать вас.

Так что первые два абзаца статьи очень спорны.
Плохо. Очередной карявый велосипед.
Для новичков, желаетльно, сразу научиться писать правильно...а не так...поэтому советую просто поиграть с CodeIgniter'ом. Очень прост в изучении и имеет отличную документацию.
Присоединяюсь к совету. Сильно просветляет голову: даёт понять об MVC и тому подобным умным фразам и сокращениям :) Использование CodeIgniter'а помогло мне перейти к ООП и постепенно начать интересоваться паттернами и так далее.
Согласен. С точки зрения обучения интересна также реализация классов работы с БД в Zend Framework.
Меня как плохого программиста, всегда бесит, когда хорошие программисты кладут болт на структуру базы:

Почему не так как ниже?

CREATE TABLE `users` (
`id` INT UNSIGNED AUTO_INCREMENT PRIMARY KEY ,
`category` TINYINT UNSIGNED,
`name` VARCHAR(25),
`password` CHAR(30),
`email` VARCHAR(100)
);
Наверное потому, что это иллюстративный материал и структура базы в данном случае не важна. Здесь много чего не затронуто - и защита от инъекций и даже о подключении к базе ни слова. Это опущено сознательно.
Я несколько раз в месяц слышу "ну поставил я индекс", применять "составные индексы" вообще заподло похоже и т.п. собственно все примеры "иллюстративные", но изначально надо показывать нормально, т.к. у подавляющего большинства и работающие структуры идентичны приведенным вами.
"данные должны поступать всегда в виде ассоциативного массива и никак иначе."

в этом случае ассоциативный массив не подойдет
list($var1, $var2) = sql_get_row('SELECT var1, var2 FROM ...');

придется юзать array_values
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории