Хочу GOTO!!!!
Kalachihin Vladimir
Ситуация:
Рекурсивная функция. В ней - цикл. Длинный и занудный кусок цикла должен быть
выполнен внутри цикла и после него.
Как оформить этот кусок, чтобы не писать дважды?
Если как функцию - он использует два десятка переменных, так что передавать в
параметрах - затрахаешься писать. Передать как глобальные - нельзя, потому что
если написать определение внутри вызывающей функции - будет переопределение.
Снаружи - вне области видимости.
Если вынести в файл и вклеивать include'ом - так каждый оборот цикла будет
обращение к файлу. Я не к этому стремился :-)
А вот в Clipper'е было понятие "блок кода"...
Калачихин Владимир.
Miguel Mitrofanov
KV> Рекурсивная функция. В ней - цикл. Длинный и занудный кусок цикла
KV> должен быть выполнен внутри цикла и после него.
Слова "рекурсивная функция" в контексте эхотага вызывают у меня
нервный смех.
KV> А вот в Clipper'е было понятие "блок кода"...
В Смолтоке до сих пор есть...
--
Miguel migue...@yandex.ru
LJ migmit http://miguel-0.narod.ru
Kalachihin Vladimir
Replying to a message of Miguel Mitrofanov to Kalachihin Vladimir:
MM> Слова "рекурсивная функция" в контексте эхотага вызывают у меня
MM> нервный смех.
Расслабься. Всё в порядке.
Калачихин Владимир.
Alex Mizrahi
(you :wrote :to '(All) :on '(Fri, 20 Oct 2006 18:15:04 +0400))
(
KV> Ситуация:
KV> Рекурсивная функция. В ней - цикл. Длинный и занудный кусок цикла
KV> должен быть выполнен внутри цикла и после него.
KV> Как оформить этот кусок, чтобы не писать дважды?
переформулировать код.
если у тебя структура кода типа
for (i = 0; i < n; ++i) do_smth;
do_another;
do_smth;
то можно сделать добавить итерацию цикла
for (i = 0; i < n + 1; ++i) {
if (i == n) do_another;
do_smth;
}
хотя скорее всего можно переформулировать и лучше.
KV> Если как функцию - он использует два десятка переменных, так что
KV> передавать в параметрах - затрахаешься писать.
скорее всего можно упаковать все переменные в "объекты" (структуры, на самом
деле).
к примеру, если нужно работать с трёхмерными координатами двух точек -- x1,
y1, z1, x2, y2, z2 -- шесть параметров, можно куда компактнее представить в
виде двух параметров типа coord3d_t.
KV> Передать как глобальные
KV> - нельзя, потому что если написать определение внутри вызывающей
KV> функции - будет переопределение. Снаружи - вне области видимости.
да ну, неужели так плохо? :)
а php не поддерживает замыкания?
на жаваскрипте можно было бы написать типа так:
function my_rec_fun (rec_params) {
var my_var1, ..;
function do_smth() { вот тут создаётся замыкание и доступны будут my_var1
и rec_params; }
for (...) { do_smth(); }
...
}
честно говоря не знаю как сейчас в пхп с этим дело, старое пхп делали
некомпетентные люди которые замыканий не знали, а в новом что-то починили, а
что-то нет.
)
(With-best-regards '(Alex Mizrahi) :aka 'killer_storm)
"People who lust for the Feel of keys on their fingertips (c) Inity")
Alex Kocharin
KV> Рекурсивная функция. В ней - цикл. Длинный и занудный кусок цикла
KV> должен быть выполнен внутри цикла и после него.
А по подробнее?
KV> Как оформить этот кусок, чтобы не писать дважды?
KV> Если как функцию - он использует два десятка переменных, так что
KV> передавать в параметрах - затрахаешься писать.
Можно передать как массив.
KV> А вот в Clipper'е было понятие "блок кода"...
Ачтойта? В понятии Clipper'а?
`-._ --- Alexander Kocharin ---
Kalachihin Vladimir
Replying to a message of Alex Kocharin to Kalachihin Vladimir:
KV>> Рекурсивная функция. В ней - цикл. Длинный и занудный кусок цикла
KV>> должен быть выполнен внутри цикла и после него.
AK> А по подробнее?
Уверен, что тебе хочется это знать? Хорошо, рассказываю:
Как известно, есть программирование структурное, а есть - оптимальное. (Есть
ещё и объектное, но в этот сон разума мы сейчас вдаваться не будем.)
Я, лично, предпочитаю на предмет оптимальности не заморачиваться, а отдавать
предпочтение структурности. Потому что структурный код обычно "достаточно
хорош", а мне его потом сопровождать...
Hо вот ситуация:
Из базы данных в соответствии с какими-то критериями извлекаются сущности (в
виде ID, натурально). Для каждой сущности надо получить некоторые свойства -
ну, там наименование, код, описание, etc. (Это называется "разименовать" :-)
Обычная задача, правда?
Как она решается структурно? Получается список сущностей, потом в цикле для
каждой сущности получается список атрибутов, потом в цикле с каждым атрибутом
что-нибудь делаем - например, печатаем. Два вложенных цикла и (число сущностей)
+ 1 запрос к базе данных.
А как оптимально? Один запрос к базе данных, в котором одновременно происходит
разименование. И ORDER BY сущности, атрибуты. В цикле перебираем полученные
записи, собираем атрибуты, и когда пошла следующая сущность - что-то делаем с
предыдущей.
Понятно откуда появилась необходимость выполнить один и тот же кусок и в цикле,
и после? Атрибуты последней сущности тоже надо обработать.
А вот теперь вопрос - а как правильно? Структурный код прост и понятен. И
другому программисту и даже мне через год. Оптимальный код выглядит диковато,
но при желании - разобраться можно. И на типичной задаче - запросов в десять
раз меньше. Ответ очевиден?
Hе тут-то было!
Я написал и так и так, и посмотрел, за сколько времени оно выполняется. Hе сам
запрос/запросы, а процедура целиком. Оказалось, структурная процедура
выполняется в среднем быстрее, чем оптимальная :-) Т.е., десять простых
запросов оказались быстрее, чем один сложный.
Правда, дисперсия величины времени выполнения оказалась больше, чем разница
между результатами структурного и оптимального кодов, т.е., - эта разница
значимо отсутствует (можно считать). При этом полученное время выполнения более
чем на порядок (десятичный) меньше, чем время передачи страницы по сети и на
два порядка меньше, чем время рендеринга страницы браузером.
Вывод - нефиг заморачиваться.
Если структурный код проще - пишите структурно. Результат будет "достаточно
хорош".
KV>> А вот в Clipper'е было понятие "блок кода"...
AK> Ачтойта? В понятии Clipper'а?
Именованный кусок кода. Идея та же, что и в include эхотага, только кусок не
обязательно в другом файле.
Калачихин Владимир.
Kalachihin Vladimir
Replying to a message of Alex Mizrahi to Kalachihin Vladimir:
AM> то можно сделать добавить итерацию цикла
Да, это забавно :-) Hадо обдумать. В принципе, может получиться.
KV>> Если как функцию - он использует два десятка переменных, так что
KV>> передавать в параметрах - затрахаешься писать.
AM> скорее всего можно упаковать все переменные в "объекты" (структуры, на
AM> самом деле).
А какая разница? В любом случае я должен в каком-то месте собрать все потребные
величины и отследить, если список изменился.
AM> а php не поддерживает замыкания?
AM> на жаваскрипте можно было бы написать типа так:
Я не знаю, что такое замыкания, но /так/ написать можно. Только я говорил, что
функция рекурсивная, и при следующем вызове функция декларируется снова. А вот
_так_ - нельзя :-)
Hо проблема, как очевидно - не принципиальная. Просто вопрос удобства :-)
Калачихин Владимир.
Miguel Mitrofanov
AM> да ну, неужели так плохо? :)
Да.
AM> а php не поддерживает замыкания?
Нет.
AM> на жаваскрипте можно было бы написать типа так:
Ну, сравнил. Жабаскрипт - язык ИМХО недооценённый.
AM> честно говоря не знаю как сейчас в пхп с этим дело, старое пхп
AM> делали некомпетентные люди которые замыканий не знали, а в новом
AM> что-то починили, а что-то нет.
Дык новое тоже.
Miguel Mitrofanov
KV> Как известно, есть программирование структурное, а есть -
KV> оптимальное.
Да ты шо!
KV> Как она решается структурно? Получается список сущностей, потом в
KV> цикле для каждой сущности получается список атрибутов, потом в
KV> цикле с каждым атрибутом что-нибудь делаем - например, печатаем.
KV> Два вложенных цикла и (число сущностей) + 1 запрос к базе данных.
Впервые слышу, чтобы маразматическая каша называлась "структурностью".
KV> А как оптимально? Один запрос к базе данных, в котором
KV> одновременно происходит разименование. И ORDER BY сущности,
KV> атрибуты. В цикле перебираем полученные записи, собираем
KV> атрибуты, и когда пошла следующая сущность - что-то делаем с
KV> предыдущей.
Опять у меня ощущение из серии "надо делать не так". То есть, у тебя
на одном уровне БД хранятся объекты и их атрибуты? Так что собственно
запросом различить никак?
KV>>> А вот в Clipper'е было понятие "блок кода"...
AK>> Ачтойта? В понятии Clipper'а?
KV> Именованный кусок кода. Идея та же, что и в include эхотага,
KV> только кусок не обязательно в другом файле.
Буэ-э-э... Обязательно именованный?
Kalachihin Vladimir
Replying to a message of Miguel Mitrofanov to Kalachihin Vladimir:
MM> Впервые слышу, чтобы маразматическая каша называлась "структурностью".
А ты не слушай, ты книжки почитай.
KV>> Один запрос к базе данных, в котором
KV>> одновременно происходит разименование. И ORDER BY сущности,
KV>> атрибуты. В цикле перебираем полученные записи, собираем
KV>> атрибуты, и когда пошла следующая сущность - что-то делаем с
KV>> предыдущей.
MM> То есть, у тебя
MM> на одном уровне БД хранятся объекты и их атрибуты? Так что собственно
MM> запросом различить никак?
Мальчик, ты дурак?
Калачихин Владимир.
Andrew Aksyonoff
[ 21 Oct 06, 19:33 ] Kalachihin Vladimir -> Alex Kocharin:
KV> Как известно, есть программирование структурное, а есть - оптимальное.
KV> (Есть ещё и объектное, но в этот сон разума мы сейчас вдаваться не
у тебя с терминологией какие-то проблемы.
KV> Как она решается структурно? Получается список сущностей, потом в
KV> цикле для каждой сущности получается список атрибутов, потом в цикле с
KV> каждым атрибутом что-нибудь делаем - например, печатаем. Два вложенных
KV> цикла и (число сущностей) + 1 запрос к базе данных. А как оптимально?
на слух звучит отвратительно.
KV> А вот теперь вопрос - а как правильно? Структурный код прост и
KV> понятен. И другому программисту и даже мне через год. Оптимальный код
KV> выглядит диковато, но при желании - разобраться можно.
покежь код.
KV> Я написал и так и так, и посмотрел, за сколько времени оно
KV> выполняется. Hе сам запрос/запросы, а процедура целиком. Оказалось,
не верю. они должны быть в лучшем случае эквивалентны с точностью
до погрешности измерений. наверняка в одном из вариантов какой-нибудь
наивный косячок. покежь код.
--
shodan
Andrew Aksyonoff
[ 22 Oct 06, 20:16 ] Kalachihin Vladimir -> Miguel Mitrofanov:
MM>> Впервые слышу, чтобы маразматическая каша называлась
MM>> "структурностью".
KV> А ты не слушай, ты книжки почитай.
MM>> То есть, у тебя на одном уровне БД хранятся объекты и их атрибуты?
MM>> Так что собственно запросом различить никак?
KV> Мальчик, ты дурак?
тебе сколько лет?
--
shodan
Alex Mizrahi
(you :wrote :to '(Alex Kocharin) :on '(Sat, 21 Oct 2006 18:33:56 +0400))
(
KV> Уверен, что тебе хочется это знать? Хорошо, рассказываю:
KV> Как известно, есть программирование структурное, а есть - оптимальное.
сам придумал?
KV> Обычная задача, правда?
KV> Как она решается структурно? Получается список сущностей, потом в цикле
KV> для каждой сущности получается список атрибутов, потом в цикле с каждым
KV> атрибутом что-нибудь делаем - например, печатаем. Два вложенных цикла и
KV> (число сущностей) + 1 запрос к базе данных.
так она решается теми, кто не умеет работать с базой данных. я не говорю об
эффективности, но банально список может быть в миллион сущностей, и у
клиента просте не хватит памяти. сервер баз данных предназначен для
эффективного хранения огромных объёмов информации. а вот сгружать её на
клиета -- плохая идея.
KV> А как оптимально? Один запрос к базе данных, в котором одновременно
KV> происходит разименование. И ORDER BY сущности, атрибуты. В цикле
KV> перебираем полученные записи, собираем атрибуты, и когда пошла
KV> следующая сущность - что-то делаем с предыдущей.
KV> Понятно откуда появилась необходимость выполнить один и тот же кусок и
KV> в цикле, и после? Атрибуты последней сущности тоже надо обработать.
нет, не понятно.
$sql = "SELECT id, name, price FROM stuff
INNER JOIN names on stuff.id = names.id
INNER JOIN prices ON prices.id = stuff.id
WHERE ORDERBY";
$rs = do_sql_query($sql);
while ($o = mysql_fetch_assoc($rs)) {
for each ($o = $name => $val) {
echo "<td>$name</td><td>$val</td>";
}
}
KV> Структурный код прост и понятен. И другому программисту и даже мне
KV> через год. Оптимальный код выглядит диковато, но при желании -
KV> разобраться можно. И на типичной задаче - запросов в десять раз меньше.
KV> Ответ очевиден?
что значит диковато?
KV> Hе тут-то было!
KV> Я написал и так и так, и посмотрел, за сколько времени оно выполняется.
KV> Hе сам запрос/запросы, а процедура целиком. Оказалось, структурная
KV> процедура выполняется в среднем быстрее, чем оптимальная :-) Т.е.,
KV> десять простых запросов оказались быстрее, чем один сложный.
KV> Правда, дисперсия величины времени выполнения оказалась больше, чем
KV> разница между результатами структурного и оптимального кодов, т.е., -
KV> эта разница значимо отсутствует (можно считать). При этом полученное
KV> время выполнения более чем на порядок (десятичный) меньше, чем время
KV> передачи страницы по сети и на два порядка меньше, чем время рендеринга
KV> страницы браузером.
потому что слишком мало объектов.
KV> Именованный кусок кода. Идея та же, что и в include эхотага, только
KV> кусок не обязательно в другом файле.
какой кошмар
Ruslan Kosolapov
KV> Hо вот ситуация: Из базы данных в соответствии с какими-то
[...]
KV> Понятно откуда появилась необходимость выполнить один и тот же
KV> кусок и в цикле, и после? Атрибуты последней сущности тоже надо
KV> обработать.
Какой ужас. Оба стиля плохие с точки зрения майнтенабилити. Если
есть сущность, то работать с ней надо как с сущностью, а не как с
набором данных.
[...]
KV> Hе тут-то было! Я написал и так и так, и посмотрел, за сколько
KV> времени оно выполняется. Hе сам запрос/запросы, а процедура
KV> целиком. Оказалось, структурная процедура выполняется в среднем
KV> быстрее, чем оптимальная :-) Т.е., десять простых запросов
KV> оказались быстрее, чем один сложный.
Два варианта - проблемы в базе (плохой дизайн, плохой тюнинг
сервера) или "оптимальный" код не является таковым.
KV> Правда, дисперсия величины времени выполнения оказалась больше,
KV> чем разница между результатами структурного и оптимального кодов,
KV> т.е., - эта разница значимо отсутствует (можно считать). При этом
KV> полученное время выполнения более чем на порядок (десятичный)
KV> меньше, чем время передачи страницы по сети и на два порядка
KV> меньше, чем время рендеринга страницы браузером.
Тем более надо юзать объекты, раз по скорости всё хорошо.
KV>>> А вот в Clipper'е было понятие "блок кода"...
AK>> Ачтойта? В понятии Clipper'а?
KV> Именованный кусок кода. Идея та же, что и в include эхотага,
KV> только кусок не обязательно в другом файле.
Это есть в любом скриптовом языке. В PHP это называется eval.
--
=[ Кто на виолончели играет, у того сильные пальцы. Там же сильно
=[ надо кнопки нажимать. -- rk
Kalachihin Vladimir
Replying to a message of Ruslan Kosolapov to Kalachihin Vladimir:
RK> Если
RK> есть сущность, то работать с ней надо как с сущностью, а не как с
RK> набором данных.
Hе могу разделить категоричность суждения.
RK> Два варианта - проблемы в базе (плохой дизайн, плохой тюнинг
RK> сервера) или "оптимальный" код не является таковым.
Hе могу разделить категоричность суждения. Думаю, есть ещё причины.
Так или иначе, я намерен исследовать этот вопрос глубже.
RK> Тем более надо юзать объекты, раз по скорости всё хорошо.
Hе могу разделить категоричность суждения. Более того, полагаю, что если
объекты можно не юзать, их юзать не надо.
KV>> Именованный кусок кода. Идея та же, что и в include эхотага,
KV>> только кусок не обязательно в другом файле.
RK> Это есть в любом скриптовом языке. В PHP это называется eval.
Уважаемый не видит _принципиальной_ разницы? Include включается (всегда, когда
это возможно) непосредственно в *текст* скрипта, перед компиляцией его в
псевдокод. Eval, напротив, никогда не включается в исходный текст, а для
обработки eval отдельно вызывается весь процесс выполнения.
Калачихин Владимир.
RK> --
RK> =[ Кто на виолончели играет, у того сильные пальцы. Там же сильно =[
RK> надо кнопки нажимать. -- rk -!- ifmail v.2.15dev5.3 ! Origin:
RK> SWSoft Novosibirsk, QA Department Second Manager (2:5020/400)
Kalachihin Vladimir
Replying to a message of Alex Mizrahi to Kalachihin Vladimir:
AM> так она решается теми, кто не умеет работать с базой данных.
Это мысль правильная, но банальная.
KV>> Понятно откуда
KV>> появилась необходимость выполнить один и тот же кусок и в цикле, и
KV>> после? Атрибуты последней сущности тоже надо обработать.
AM> нет, не понятно.
А ты подумай.
AM> $sql = "SELECT id, name, price FROM stuff
AM> INNER JOIN names on stuff.id = names.id
AM> INNER JOIN prices ON prices.id = stuff.id
AM> WHERE ORDERBY";
AM> $rs = do_sql_query($sql);
AM> while ($o = mysql_fetch_assoc($rs)) {
AM> for each ($o = $name => $val) {
AM> echo "<td>$name</td><td>$val</td>";
AM> }
AM> }
Это код чудовищен. Твой разум спал?
Давай посмотрим, как твою мысль можно выразить иначе.
Hачнём с запроса. Твой содержит синтаксические ошибки и смысловые неточности
(полагаю, в спешке), а форма его замысловата. Hапишем так:
$sql = "SELECT stuff.id, names.name, prices.price
FROM stuff, names, prices
WHERE names.id = stuff.id AND price.id = stuff.id AND ....
ORDER BY stuff.id, ....";
Тебя интересует просто пересечение множеств - зачем засорять выражение словами
"объединение"?
Теперь код. Думаю, твоё $rs = do_sql_query($sql) - это получение идентификатора
ресурса.
$rs = do_sql_query($sql);
while( list( $id, $name, $price) = mysql_fetch_row( $rs)) {
echo "<td>$id</td><td>$name</td><td>$price</td>";
}
Так проще, правда?
Теперь вернёмся к тому, что тебе непонятно.
Я сказал:
KV>> Понятно откуда
KV>> появилась необходимость выполнить один и тот же кусок и в цикле, и
KV>> после? Атрибуты последней сущности тоже надо обработать.
Посмотри на свой оператор echo и сравни с моим. Давай придадим им
реалистичности.
Во-первых, ты стыдливо опустил вывод $id, когда как в запросе не указал, что
тебя интересует какой-то конкретный id. Значит, несколько? Давай захотим, чтобы
для каждого id печатались name - price, а в конце - черта и сумма.
Для этого, как я сказал раньше -
KV> В цикле перебираем полученные записи, собираем атрибуты, и когда пошла
KV> следующая сущность - что-то делаем с предыдущей.
Т.е., применительно к данному конкретному примеру - при смене id потребуется
нарисовать черту и сумму предыдущего. Когда цикл закончится, надо будет сделать
это ещё раз.
Так понятно? Т.е., твой пример не является иллюстрацией того, что в принципе
можно без обязательного выполнения куска из тела цикла после окончания цикла. В
лучшем случае - это частный пример того, когда этого не надо по смыслу -
откажемся от действий по исчерпании атрибутов, и всё. Hо это только частный
случай.
KV>> Оптимальный код выглядит диковато, но при желании -
KV>> разобраться можно.
AM> что значит диковато?
Hу вот твой код написан с порождением ненужных сущностей. Он чудовищен. А если
написать с порождением неочевидных сущностей - будет просто диковато.
(Вот в разбираемом примере нужна специальная переменная для хранения "текущего"
id. Сравнивая id из запроса с ней, мы отслеживаем момент смены id. Hо с
прикладной точки зрения она нафиг не нужна. Это чисто служебная переменная)
AM> потому что слишком мало объектов.
Слишком мало объектов - где? Вообще? Выбрано запросом?
KV>> Именованный кусок кода. Идея та же, что и в include эхотага, только
KV>> кусок не обязательно в другом файле.
AM> какой кошмар
Hе кошмарней include.
Калачихин Владимир.
Alex Mizrahi
(you :wrote :to '(Alex Mizrahi) :on '(Mon, 23 Oct 2006 13:31:52 +0400))
(
AM>> $sql = "SELECT id, name, price FROM stuff
AM>> INNER JOIN names on stuff.id = names.id
AM>> INNER JOIN prices ON prices.id = stuff.id
AM>> WHERE ORDERBY";
AM>> $rs = do_sql_query($sql);
AM>> while ($o = mysql_fetch_assoc($rs)) {
AM>> for each ($o = $name => $val) {
AM>> echo "<td>$name</td><td>$val</td>";
AM>> }
AM>> }
KV> Это код чудовищен. Твой разум спал?
сам дурак
KV> а форма его замысловата. Hапишем так:
KV> $sql = "SELECT stuff.id, names.name, prices.price
KV> FROM stuff, names, prices
KV> WHERE names.id = stuff.id AND price.id = stuff.id AND ....
KV> ORDER BY stuff.id, ....";
KV> Тебя интересует просто пересечение множеств - зачем засорять выражение
KV> словами "объединение"?
не тебе меня учить SQL. это дело вкуса.
ты знаешь, что кроме INNER JOIN есть LEFT, RIGHT и FULL JOIN? какой именно
JOIN у тебя?
KV> Теперь код. Думаю, твоё $rs = do_sql_query($sql) - это получение
KV> идентификатора ресурса.
KV> $rs = do_sql_query($sql);
KV> while( list( $id, $name, $price) = mysql_fetch_row( $rs)) {
KV> echo "<td>$id</td><td>$name</td><td>$price</td>";
KV> }
KV> Так проще, правда?
проще вот так:
while ($o = mysql_fetch_object($rs)) {
echo "<td>$o->id</td><td>$o->name</td><td>$o->price</td>";
}
тогда нет нужды в избыточных определениях имён полей подвараза подвараза.
KV> Значит, несколько? Давай захотим, чтобы для каждого id печатались name
KV> - price, а в конце - черта и сумма. Для этого, как я сказал раньше -
KV>> В цикле перебираем полученные записи, собираем атрибуты, и когда пошла
KV>> следующая сущность - что-то делаем с предыдущей.
по-моему _значительно_ проще посчитать это через SQL.
можно даже одним запросом -- with cube или with rollup.
но если не хочешь -- двумя, я думаю, вполне нормально.
function print_object($o) {
echo "<td>$o->id</td><td>$o->name</td><td>$o->price</td>";
}
function my_rec_fun() {
$sql = "SELECT id, name, price FROM stuff ..";
$rs = mysql_query($sql);
while ($o = mysql_fetch_object($rs)) { print_object($o); }
$sql = "SELECT "--" as id, "summ" as name, SUM(price) as price FROM stuff
..";
$rs = mysql_query($sql);
$o = mysql_fetch_object($rs); print_object($o);
}
идея ясна?
KV> Hу вот твой код написан с порождением ненужных сущностей.
твой код написан с порождением ненужных сущностей -- ты написал два раза
имена полей.
если они изменятся -- тебе прийдётся менять в двух местах. если ты допустишь
опечатку хотя бы в одном из них -- программа перестанет корректно работать,
вероятность ошибки увеличивется в два раза.
KV> Он чудовищен.
я твоего кода не видел, но считаю что все кто писал на клиппере пишут
чудовищно
KV> Слишком мало объектов - где? Вообще? Выбрано запросом?
ну типа когда в базе будет поболе храниться, разница возрастёт.
AM>> какой кошмар
KV> Hе кошмарней include.
я привык пользоваться языками с большими выразительными возможностями, так
что оно и инклюд для меня одинаково кошмарны :).
Kalachihin Vladimir
Replying to a message of Alex Mizrahi to Kalachihin Vladimir:
AM> сам дурак
Мудро.
AM> не тебе меня учить SQL.
А почему, собственно? Вот ты (риторически, надо полагать) вопрошаешь:
AM> ты знаешь, что кроме INNER JOIN есть LEFT, RIGHT и FULL JOIN?
Я - знаю.
Потом ты интересуешься:
AM> какой
AM> именно JOIN у тебя?
И я понимаю, что семантика запятой в списке таблиц тебе неизвестна. А мне,
прикинь - известна.
Если тебя ломает учиться у меня - прочти, хотя бы, инструкцию?
AM> тогда нет нужды в избыточных определениях имён полей подвараза
AM> подвараза.
И гдеж-это я определял имена полей аж "подвараза подвараза"? Полей чего,
позволь мне спросить?
AM> по-моему _значительно_ проще посчитать это через SQL.
Ты опять, столь же мило, как и в прошлый раз, опустил суть вопроса. Забудь о
сумме - просто нарисуй цветочек в конце.
AM> твой код написан с порождением ненужных сущностей -- ты написал два
AM> раза имена полей. если они изменятся -- тебе прийдётся менять в двух
AM> местах.
А, я понял. "подвараза подвараза" - это я не "определял поля". Это я сперва
присвоил значение переменной, а потом - разименовал.
Hичего, это не страшно. Зато понятно. Код придётся сопровождать.
AM> я твоего кода не видел, но считаю что все кто писал на клиппере пишут
AM> чудовищно
Прикинь - я никогда не писал на Клиппере.
KV>> Слишком мало объектов - где? Вообще? Выбрано запросом?
AM> ну типа когда в базе будет поболе храниться, разница возрастёт.
Мудро. Hа сколько?
Калачихин Владимир.
Alex Mizrahi
(you :wrote :to '(Alex Mizrahi) :on '(Mon, 23 Oct 2006 21:46:18 +0400))
(
AM>> какой
AM>> именно JOIN у тебя?
KV> И я понимаю, что семантика запятой в списке таблиц тебе неизвестна. А
KV> мне, прикинь - известна.
нет, мне известна. но мне больше нравится когда явно указывается какой тип
джоина тут используется.
KV> Если тебя ломает учиться у меня - прочти, хотя бы, инструкцию?
читал, не боись. но, понимаешь ли, мой круг задач не ограничивается SQL'ом и
PHP как у большинства клепателей бухгателерских приложений и сайтиков.
поэтому я предпочитаю когдя явно написано, а не приходится
вспоминать/угадывать.
AM>> тогда нет нужды в избыточных определениях имён полей подвараза
AM>> подвараза.
KV> И гдеж-это я определял имена полей аж "подвараза подвараза"? Полей
KV> чего, позволь мне спросить?
каждое поле упоминается два раза -- во время извлечения из бд и в теле цикла
во время вывода.
KV> Hичего, это не страшно. Зато понятно. Код придётся сопровождать.
тебе понятно так. а другим более понятно по-другому. ты прикинь.
я, к примеру, предпочитаю когда код написан предельно кратко, но без фокусов
(т.е. не краткость любой ценой). могу даже подвести под это научную базу --
к примеру, статью Paul Graham'а 'Succinctness is power", в которой он
проводит исследования, ссылаясь на ряд работ в этой области.
KV> Прикинь - я никогда не писал на Клиппере.
значит ещё не всё потеряно :)
KV>>> Слишком мало объектов - где? Вообще? Выбрано запросом?
AM>> ну типа когда в базе будет поболе храниться, разница возрастёт.
KV> Мудро. Hа сколько?
в последней статье которую я читал на daily wtf упоминается примерно
подобный случай -- разница в 30 раз (по одному запросы -- 3 часа, а один
умный запрос -- 5 минут). впрочем на том количестве записей которое они
упоминают возникает вопрос -- чо так долго, в обоих случаях.
но в общем ты понял -- разница может быть на порядок. когда куча отдельных
запросов к базе данных будет отправляться синхронно по сети, оно просто
обязанно тормозить :). хотя у тебя если все данные выводятся на экран, их не
может быть ОЧЕНЬ МНОГО.
но ведь привыкнув делать так, ты будешь так писать и когда они не выводятся
на экран, и сможешь повторить случай на daily wtf :). и кто нибудь читающий
твой код на предмет чо так тормозит воскликнет -- "шо за нафиг??".
вот пример из daily wtf, плохой код:
//SQL Query to retreive all unbroadcast messages
string sqlCmd =
"SELECT o.*, r.*, ..., c.*, u.* " +
" FROM Orgs o, Recipients r, Contacts C, " +
" ... " +
" Groups g, Users u " +
" WHERE m.Group_Id = g._Group_Id " +
" AND u.User_Id = gu.User_Id " +
" AND ... " +
" ORDER BY o.Priority_Code, o.Delivery_Num, ...";
//Execute SqlCommand
DataTable dt = DataHelper.ExecSqlToTable(sqlCmd);
//For each row retreived, insert a row into the Queue table
for(int i=0; i<dt.Rows.Count; i++)
{
//Insert Sql command
SqlCommand insCmd = DataHelper.CreateCmd(
"INSERT INTO Queue (Sender_Id, Recipient_Id, ...) " +
" VALUES (@Sender_Id, @Recipient_Id, ...))";
//Add Parameters to command
AppendParam( insCmd, "@Sender_Id", dt.Rows[i]["Sender_Id"]);
AppendParam( insCmd, "@Recipient_Id", dt.Rows[i]["@Recipient_Id"]);
...
//execute command
insCmd.ExecuteNonQuery();
}
хороший код:
INSERT INTO Queue (...) SELECT ... FROM Messages m, Recipients r, ...
It ran in less than five minutes instead of several hours.
Ruslan Kosolapov
RK>> Если есть сущность, то работать с ней надо как с сущностью, а не
RK>> как с набором данных.
KV> Hе могу разделить категоричность суждения.
Твоё дело. Потом замаешься с поддержкой. Уровни абстракции и их
изоляция не на пустом месте возникли.
Собственно ты УЖЕ нарушаешь DRY, то есть увеличиваешь багоопасность
и снижаешь майнтенабилити. Про то, что ты смешиваешь уровни, можно
не говорить - в твоём случае минусы этого не так очевидны, как
минусы копипаста.
RK>> Два варианта - проблемы в базе (плохой дизайн, плохой тюнинг
RK>> сервера) или "оптимальный" код не является таковым.
KV> Hе могу разделить категоричность суждения. Думаю, есть ещё
KV> причины. Так или иначе, я намерен исследовать этот вопрос
KV> глубже.
Эээ... По-моему просто по определению других вариантов не может
быть. Дихотомия-с.
RK>> Тем более надо юзать объекты, раз по скорости всё хорошо.
KV> Hе могу разделить категоричность суждения. Более того, полагаю,
KV> что если объекты можно не юзать, их юзать не надо.
Ну, изобретай велосипед дальше, удачи.
KV>>> Именованный кусок кода. Идея та же, что и в include эхотага,
KV>>> только кусок не обязательно в другом файле.
RK>> Это есть в любом скриптовом языке. В PHP это называется eval.
KV> Уважаемый не видит _принципиальной_ разницы? Include включается
KV> (всегда, когда это возможно) непосредственно в *текст* скрипта,
KV> перед компиляцией его в псевдокод. Eval, напротив, никогда не
KV> включается в исходный текст, а для обработки eval отдельно
KV> вызывается весь процесс выполнения.
Не нашёл в документации по этому поводу ничего вразумительного
(правда, искал не очень активно). Please ссылку или тест, которые
это всё наглядно показывают.
Однако таки не понимаю проблемы, если по скорости есть нехилый
запас, как ты сказал. Раз скорость не роялит, то значит надо писать
так, как удобно поддерживать.
--
=[ Сэры, это, на циску не надо чайник ставить!
=[ -- vi, 2004
Kalachihin Vladimir
Replying to a message of Alex Mizrahi to Kalachihin Vladimir:
AM> тебе понятно так. а другим более понятно по-другому. ты прикинь.
Может, другим следует почитаь книжку? Hе типа "за 5 минут", а нормальную? И
тогда им не будет понятно "по другому", а будет понятно правильно?
AM> но в общем ты понял -- разница может быть на порядок.
"Может" - это не значит "должна", правильно?
AM> хотя у тебя если все
AM> данные выводятся на экран, их не может быть ОЧЕHЬ МHОГО.
Откуда ты взял, что у меня все данные выводятся на экран?
AM> вот пример из daily wtf, плохой код:
Ты третий раз на протяжении этого содержательного разговора опускаешь его
предмет. Зачем мне пример из daily wtf, если я сколько-то писем назад привёл
тебе такой же свой?
Или, типа, у дядей всё плохо - так значит и все такие? Hу-ну...
Калачихин Владимир.
Alex Mizrahi
(you :wrote :to '(Alex Mizrahi) :on '(Tue, 24 Oct 2006 10:32:08 +0400))
(
AM>> тебе понятно так. а другим более понятно по-другому. ты прикинь.
KV> Может, другим следует почитаь книжку? Hе типа "за 5 минут", а
KV> нормальную? И тогда им не будет понятно "по другому", а будет понятно
KV> правильно?
о, вопрошающий снова порывается меня учить?
а ты что вообще читал? есть ли у тебя достаточно знаний по теории вычислений
вообще -- какими могут быть языки программирования, как могут задаваться
алгоритмы?
или ты знаешь только несколько алголоподобных языков, и считаешь это
наиболее правильным образом программирования? вынужден тебя разочаровать --
это самый примитивный и кривой способ, по сути.
ты не знаешь что такое замыкания -- но как ты тогда будешь программировать
на JavaScript, скажем?
или может ты читал нечто о теории как писать поддерживаемый код?
я привёл тебе ссылку на статью -- как ты её можешь прокоментировать?
AM>> но в общем ты понял -- разница может быть на порядок.
KV> "Может" - это не значит "должна", правильно?
в определённой ситуации будет.
AM>> вот пример из daily wtf, плохой код:
KV> Ты третий раз на протяжении этого содержательного разговора опускаешь
KV> его предмет. Зачем мне пример из daily wtf, если я сколько-то писем
KV> назад привёл тебе такой же свой?
я твой код не видел.
KV> Или, типа, у дядей всё плохо - так значит и все такие? Hу-ну...
глупец не понимает сходства ситуаций и не может учиться на чужих ошибках. ну
пускай тогда он учится на своих.
Miguel Mitrofanov
KV>> Может, другим следует почитаь книжку? Hе типа "за 5 минут", а
KV>> нормальную? И тогда им не будет понятно "по другому", а будет
KV>> понятно правильно?
AM> о, вопрошающий снова порывается меня учить?
Бобёр, выды... Алекс, игнорь. Проще будет.
AM> ты не знаешь что такое замыкания -- но как ты тогда будешь
AM> программировать на JavaScript, скажем?
Как-как... Как на похапе, только хуже.
KV>> Ты третий раз на протяжении этого содержательного разговора
KV>> опускаешь его предмет. Зачем мне пример из daily wtf, если я
KV>> сколько-то писем назад привёл тебе такой же свой?
AM> я твой код не видел.
Чует моё сердце - и не увидишь.
Kalachihin Vladimir
Replying to a message of Alex Mizrahi to Kalachihin Vladimir:
AM> о, вопрошающий снова порывается меня учить?
Да. Тебя ещё учить и учить - ты в простом запросе сделал одну синтаксическую и
одну смысловую ошибки.
AM> а ты что вообще читал? есть ли у тебя достаточно знаний по теории
AM> вычислений вообще
Есть, а что? Тебе что показывать - корочки или трудовую книжку? Или книги из
домашней библиотеки? У меня "Справочник металлиста" есть... Hет, ты "Ленинград"
любишь, это не металл... Слушай, а прям в Донецк ехать показывать?
Как ещё оправдаться перед студентом математического факультета Донецкого гос.
университета?
Думаю, мне без мазы - я хоть окончил Московский, но геологический факультет...
А вот у меня в трудовой написано "ведущий инженер-программист" - годится?
Правда, это лет пятнадцать назад было...
Калачихин Владимир.
Ща придёт модератор - и всем наваляет. Hо у меня отмазка - я хотя бы требование
подписываться настоящим именем выполняю...