Вы хоть раз его использовали.
У нашего клиента база более полутора миллиона записей транзакций (не считая остального), около 30 рабочих мест, десятки транзакций в секунду и все работает просто отлично.
Ну даже если такой конкурс и есть, то почему рассылка от одного имени, а при регистрации указывается другое? Как-то нелогично это.
Да и письма приходят с адреса "Администрация KM.RU", логично предположить, что пользователь их отправляет тогда через веб-форму, это как же надо стараться, чтобы тысячи адресов туда вписывать.
Вот, кстати, что стоит в заголовке письма (стало интересно):
Received-SPF: pass (mxfront26: domain of hosting03.io-hosts.ru designates 62.16.108.103 as permitted sender) client-ip=62.16.108.103; envelope-from=www-data@hosting03.io-hosts.ru; helo=hosting03.io-hosts.ru;
Received: from www-data by hosting03.io-hosts.ru with local (Exim 4.63)
(envelope-from <www-data@hosting03.io-hosts.ru>)
id 1KGBb4-0000ip-LL
for XXXXXXX@yandex.ru; Tue, 08 Jul 2008 15:43:02 +0400
To: XXXXXXX@yandex.ru
Subject: Анна Гончарова приглашает Вас на Одноклассники KM.RU.
From: <Одноклассники KM.RU <support@odnoklassniki.km.ru> >
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: PHP/5.2.0-8+etch11
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="1215517382SPB"
Message-Id: <E1KGBb4-0000ip-LL@hosting03.io…>
Sender: www-data <www-data@hosting03.io-hosts.ru>
Date: Tue, 08 Jul 2008 15:43:02 +0400
X-SA-Exim-Connect-IP:
X-SA-Exim-Mail-From: www-data@hosting03.io-hosts.ru
X-SA-Exim-Scanned: No (on hosting03.io-hosts.ru); SAEximRunCond expanded to false
> да давуно я VB кода не видел,воспоминания мои не добрые
Да я бы тоже с радостью его не видел, но приходится поддерживать системы, написанные еще лет 10-12 назад...
> автару респект,за то что сам,сделал и поделился
Спасибо за плюсик!
У меня таких наработок много, буду потихоньку выкладывать...
Только что проверил у себя никаких проблем не заметил. Файлы, созданные на XP, без проблем открывались и пересохранялись. Правда с локального диска, по сети не пробовал...
Тут от PHP совсем чуть-чуть, скорее это тест на общий кругозор.
Вот я никаким местом не PHP-программист, но безо всякого труда могу ответить на 90% вопросов (все кроме функций работы с массивами).
Но понятно, что так и нужно людей отбирать на работу, выучить функции работы с массивами и типы данных дело 5 минут, если ты работал с ними и знаешь, когда тебе нужен массив, а когда хеш-таблица.
По крайней мере на MS SQL Server 2000 и MS Access 2003 работает ровно столько же, ибо оптимизатор запросов легко оптимизирует данные запрос. Тут, наоборот, как раз важно писать count(*), потому что такой запрос очень быстро оптимизируется (в отличие от счета по определенным полям).
SQL сервера сейчас пошли очень умные, не стоит их недооценивать :)
1. Согласен.
2. Это все-таки уже на мой взгляд наука, либо очень специализированная практика. В рамках наших проектов самый низкий уровень, до которого может опуститься техлид это анализ загрузки сервера и оптимизация "долгих" запросов. Это даст на порядок более высокий прирост, нежели оптимизация сортировки (особенно учитывая тот факт, что большинство крупных проектов все-таки пишется в managed code, и там эта ситуация теоретически невозможна!).
3. В Boost эта куча реализована, в принципе работает шустро, основные операции кучи выполняются в линейное время и константа c (если вы о ней говорите) вроде бы вполне приемлима. Бесмысленно это конечно для массива размером до 2 в 10-20, там быстрее воспользоваться чем-то другим (и если не нравится Quicksort, можно попробовать merge sort, он устойчивее к исходной организации массива). Такие изощрения нужны уже в очень крайних случаях, которые я при всем желании не вижу в рамках бизнес-приложения.
4. :) И тем не менее, на практике основание как раз важно, это в теории оно не важно. Именно это я и хотел сказать. А что там еще на что влияет это только Богу и известно...
Прошу прощения, что я вмешиваюсь, но:
1. В указанном запросе вообще нет никаких join'ов, автор пытается показать, что не все могут даже простую аггрегатную функцию записать в SQL. Но это, похоже, универсальная проблема.
2. В любой базе данных, начиная с Jet и заканчивая Oracle работает свой query optimizer, который использует в том числе и различные евристики для оптимизации выполнения запросов. Техлиду, да что там даже программисту --, совсем не нужно знать особенности обработки запросов этим query optimizer, достаточно знать общие принципы SQL чтобы писать запросы, которые уже будут дальше правильно оптимизированы самим движком базы. И поверьте, join'ы выполняются сейчас всеми движками на ура, проблемы вызывают только вложенные запросы (типа функций exists, within, contents) и какие-нибудь криво написанные скалярные функции (поскольку их база естественно не умеет оптимизировать).
1. А зачем это знать мне, если я не только не работаю с STL, но и вообще с C++ как таковым?
2. То знание, что требуете Вы это уже из области науки, алгоритмики и большей частью оптимизации. В рамках обычного технического проекта хорошо, на мой взгляд, если техлид понимает что такое quicksort и его омега, и сосредотачивается на других вопросах.
3. Сортировка кучей и на больших массивах будет работать вполне приемлимо, при грамотной реализации кучи, например в виде кучи Фибоначи.
4. Какое основание у логарифма еще как важно :) Если Вы хотите сказать, что при этом не изменится значение омеги то это одно дело. Но как Вы сами пишете выше, теория от практики отличается порой значительно, а тем более complexity theory.
У нашего клиента база более полутора миллиона записей транзакций (не считая остального), около 30 рабочих мест, десятки транзакций в секунду и все работает просто отлично.
На всякий случай добавил в пост disclaimer в конец поста.
Да и письма приходят с адреса "Администрация KM.RU", логично предположить, что пользователь их отправляет тогда через веб-форму, это как же надо стараться, чтобы тысячи адресов туда вписывать.
Вот, кстати, что стоит в заголовке письма (стало интересно):
Received-SPF: pass (mxfront26: domain of hosting03.io-hosts.ru designates 62.16.108.103 as permitted sender) client-ip=62.16.108.103; envelope-from=www-data@hosting03.io-hosts.ru; helo=hosting03.io-hosts.ru;
Received: from www-data by hosting03.io-hosts.ru with local (Exim 4.63)
(envelope-from <www-data@hosting03.io-hosts.ru>)
id 1KGBb4-0000ip-LL
for XXXXXXX@yandex.ru; Tue, 08 Jul 2008 15:43:02 +0400
To: XXXXXXX@yandex.ru
Subject: Анна Гончарова приглашает Вас на Одноклассники KM.RU.
From: <Одноклассники KM.RU <support@odnoklassniki.km.ru> >
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: PHP/5.2.0-8+etch11
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="1215517382SPB"
Message-Id: <E1KGBb4-0000ip-LL@hosting03.io…>
Sender: www-data <www-data@hosting03.io-hosts.ru>
Date: Tue, 08 Jul 2008 15:43:02 +0400
X-SA-Exim-Connect-IP:
X-SA-Exim-Mail-From: www-data@hosting03.io-hosts.ru
X-SA-Exim-Scanned: No (on hosting03.io-hosts.ru); SAEximRunCond expanded to false
Да я бы тоже с радостью его не видел, но приходится поддерживать системы, написанные еще лет 10-12 назад...
> автару респект,за то что сам,сделал и поделился
Спасибо за плюсик!
У меня таких наработок много, буду потихоньку выкладывать...
Вот я никаким местом не PHP-программист, но безо всякого труда могу ответить на 90% вопросов (все кроме функций работы с массивами).
Но понятно, что так и нужно людей отбирать на работу, выучить функции работы с массивами и типы данных дело 5 минут, если ты работал с ними и знаешь, когда тебе нужен массив, а когда хеш-таблица.
SQL сервера сейчас пошли очень умные, не стоит их недооценивать :)
2. Это все-таки уже на мой взгляд наука, либо очень специализированная практика. В рамках наших проектов самый низкий уровень, до которого может опуститься техлид это анализ загрузки сервера и оптимизация "долгих" запросов. Это даст на порядок более высокий прирост, нежели оптимизация сортировки (особенно учитывая тот факт, что большинство крупных проектов все-таки пишется в managed code, и там эта ситуация теоретически невозможна!).
3. В Boost эта куча реализована, в принципе работает шустро, основные операции кучи выполняются в линейное время и константа c (если вы о ней говорите) вроде бы вполне приемлима. Бесмысленно это конечно для массива размером до 2 в 10-20, там быстрее воспользоваться чем-то другим (и если не нравится Quicksort, можно попробовать merge sort, он устойчивее к исходной организации массива). Такие изощрения нужны уже в очень крайних случаях, которые я при всем желании не вижу в рамках бизнес-приложения.
4. :) И тем не менее, на практике основание как раз важно, это в теории оно не важно. Именно это я и хотел сказать. А что там еще на что влияет это только Богу и известно...
1. В указанном запросе вообще нет никаких join'ов, автор пытается показать, что не все могут даже простую аггрегатную функцию записать в SQL. Но это, похоже, универсальная проблема.
2. В любой базе данных, начиная с Jet и заканчивая Oracle работает свой query optimizer, который использует в том числе и различные евристики для оптимизации выполнения запросов. Техлиду, да что там даже программисту --, совсем не нужно знать особенности обработки запросов этим query optimizer, достаточно знать общие принципы SQL чтобы писать запросы, которые уже будут дальше правильно оптимизированы самим движком базы. И поверьте, join'ы выполняются сейчас всеми движками на ура, проблемы вызывают только вложенные запросы (типа функций exists, within, contents) и какие-нибудь криво написанные скалярные функции (поскольку их база естественно не умеет оптимизировать).
2. То знание, что требуете Вы это уже из области науки, алгоритмики и большей частью оптимизации. В рамках обычного технического проекта хорошо, на мой взгляд, если техлид понимает что такое quicksort и его омега, и сосредотачивается на других вопросах.
3. Сортировка кучей и на больших массивах будет работать вполне приемлимо, при грамотной реализации кучи, например в виде кучи Фибоначи.
4. Какое основание у логарифма еще как важно :) Если Вы хотите сказать, что при этом не изменится значение омеги то это одно дело. Но как Вы сами пишете выше, теория от практики отличается порой значительно, а тем более complexity theory.
Про себя не техлид.