Дорогие друзья,
настал момент, который не мог не настать. Все мы растем и развиваемся, совершаем какое-то движение, преимущественно вверх и вперед, что не может не радовать.
Руководствуясь всем лучшим, что есть во мне, я открываю новую страницу своей жизни, которая не вполне вписывается в концепцию и историю этого журнала. Журнал не будет удален, т.к. я чту свою память и прошлое, свой опыт. Но, для того, чтобы открыть в себе что-то новое, надо почувствовать внутреннюю свободу от старых ярлыков и стереотипов, поэтому и журнал у меня будет новый.

Если мы с вами друзья, то скорее всего в ближайшее время я путем личного сообщения уведомлю вас о том, где меня искать. Если мы с вами близкие друзья, то у вас есть мой телефон. Я не пропадаю из жизни, я просто меняю форму и содержание. По-прежнему буду рада встретиться в реале и выпить кружечку чая. Вы так же можете оставить свой комментарий к этой записи, если у вас есть какие-то вопросы или проблемы со связью со мной.

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

Большое спасибо всем. До скорой встречи.

Respect the Past & Create the New ©

Этот пост - по работе, носит технический и исследовательский характер, составлен для потомков. Не рекомендуется к прочтению лицам со слабой психикой.

В предыдущей научно-публицистической заметке про способы кэширования данных, я сделала вывод, что наиболее эффективным методом (по скорости чтения кэша) является метод чтения кэша БЕЗ прочтения PRIMARY INDEX таблицы. Я решила исследовать этот вопрос более подробно.

Собственно, в Microsoft Access при работе со связанными таблицами через DAO.Recordset, если вы читаете в запросе PRIMARY INDEX таблицы, то драйвер обязует вас использовать определенный вид КУРСОРА и БЛОКИРОВКИ: dbSeeChanges, dbOpenDynaset:



Сначала, я подумала (не без влияния общественного мнения, конечно), что от DAO.Recordset мне стоит отказаться и перейти на более "модный" и продвинутый ADODB.Recordset. В народе бытует мнение, что он быстрее. Я решила это проверить, но результаты оказались настолько неожиданны, на сколько и ВЫВОДЫ :)))

Итак, провела очередную серию испытаний, в ходе которых следовало установить скорость работы различных Recordset с РАЗНЫМИ видами курсоров и блокировок.

Тест: Прохождение Recordset
Данные: Таблица контрагентов
Алгоритм: циклическое открытие рекордсета с полным прохождением
Железо: AMD Athlon XP 1600+ (1.4GHz), 2x256 MB RAM, Chipset nForce2 Ultra (dual channel)
Софт: Windows XP, SQL Server 2005, MS Access 2003
Нагрузка: (428 строк, 47 полей) x 10 открытий и прохождений
Условия: Все испытания проводились дважды с полным совпадением результатов.
Метод вычислений: замер времени в контрольных точках начала и конца заполнения и прочтения таблицы (7300 строк)
Погрешность вычислений: 0.5 секунды

Варианты тестирования:

• DAO.Recordset, ADODB.Recordset

• с использованием динамического курсора и без

Результаты тестирования

Варианты тестирования	Dynamic курсор	Static курсор (обычный)
DAO.Recordset	9 минут	2 секунды
ADODB.Recordset	7 минут	40 секунд

Эти уникальные данные доказывают, что применение ADODB.Recordset имеет весьма сомнительное преимущество по скорости. Если точнее, то относительно небольшое преимущество можно получить только, если используются динамические курсоры, но преимущество все равно слабое.

Меня поразила скорость работы DAO.Recordset со статическим курсором и я придумала одну ХИТРОСТЬ, как получать значение PRIMARY INDEX, без чтения САМОГО индекса, что избавит от необходимости использования динамического курсора в DAO.

Совершенно случайно на прошлой неделе наткнулась на возможность создания в MS MSQL SERVER 2005 полей таблиц, со свойством COMPUTED COLUMN SPECIFICATION. Этот параметр (а так же PERSISTED=No), позволяют создать вычисляемое ВИРТУАЛЬНОЕ поле таблицы на стороне сервера, используя формулу.

Мы просто создаем поле, у которого в формулу вписываем название поля с PRIMARY INDEX и получаем дубликат PRIMARY INDEX, который сам таковым при выборке не является. Теперь я могу работать с DAO.Recordset за доли секунд за счет этого метода.

Этот пост - по работе, носит технический и исследовательский характер, составлен для потомков. Не рекомендуется к прочтению лицам со слабой психикой.

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

Исходные данные.
Тест: Отсрочка в рабочих днях
Данные: таблица праздников
Алгоритм: собственный, с применением рекурсии, используются два параметра (начальная дата, число дней для отсрочки), на выходе - конечная дата для последующего кэширования.
Железо: AMD Athlon XP 1600+ (1.4GHz), 2x256 MB RAM, Chipset nForce2 Ultra (dual channel)
Софт: Windows XP, SQL Server 2005, MS Access 2003
Нагрузка: 20x365 = 7300 циклов тестирования (вычисление отсрочки в рабочих днях от 01.01.2010)
Условия: при всех изменениях таблицы производился пересчет индекса UPDATE STATISTICS. Все испытания проводились дважды с полным совпадением результатов.
Метод вычислений: замер времени в контрольных точках начала и конца заполнения и прочтения таблицы (7300 строк)
Погрешность вычислений: 0.5 секунды

Варианты тестирования.
а) текстовый индекс.
поля таблицы:
cache_type varchar
cache_key varchar
cache_value varchar
индекс: (cache_type & cache_key)

б) primary & текстовый индексы
поля таблицы:
rid int
cache_type varchar
cache_key varchar
cache_value varchar
индексы: (rid), (cache_type & cache_key)

в) primary & числовые индексы ключа
поля таблицы:
rid int
cache_type varchar
cache_idx1 int
cache_idx2 int
cache_value varchar
индексы: (rid), (cache_type & cache_idx1 & cache_idx2)

г) primary & все числовые индексы
поля таблицы:
rid int
cache_type_id int
cache_idx1 int
cache_idx2 int
cache_value varchar
индексы: (rid), (cache_type_int & cache_idx1 & cache_idx2)

д) вариант "г" + использование подтаблицы типов кэша, ключ которых подставляется в cache_type_id

Результаты тестирования.

Метод	Запись	Чтение
а) текстовый индекс	2:57	2:10
б) primary & текстовый индексы	--"--	2:30
б) primary & текстовый индексы БЕЗ чтения самого primary индекса (rid)	--"--	0:33
в) primary & числовой индекс ключа	--"--	0:35
г) primary & все числовые индексы	--"--	0:34
д) г + использование справочной таблицы типов кэша	3:05	1:25

Анализ результатов.
1. Изменение типа кэширования не влияет на скорость записи в кэш, за исключением использования дополнительных таблиц.
2. Использование PRIMARY INDEX значительно ускоряет чтение кэша, ОДНАКО ПРИ УСЛОВИИ, что самого чтения индекса не производится. В противном случае происходит сильное замедление чтения.
3. Использование одного сериализованного ключа кэша (составной ключ в одном поле) не замедляет чтение, хотя и увеличивает объем хранимых данных
4. Использование нескольких числовых ключей вместо одного сериализованного не дает преимущества в скорости, хотя сокращает объем данных
5. Использование дополнительной таблицы замедляет процессы записи и (в значительной степени) чтения кэша, тем не менее, сокращая объем данных.

Вывод.
1. Для задач, требующих высокую скорость обработки кэша, рекомендуется использовать простую таблицу, состояющую из primary index, текстового (возможно-сериализованного) ключа кэша и значения кэша, однако, на этапе чтения, не следует читать из базы primary index.
2. Для задач, в которых помимо скорости критичен общий объем занимаемого базой данных места на диске, рекомендуется использование числовых индексов в кэше, с использованием нескольких полей. Числовой параметр типа кэша должен обрабатываться и задаваться программными средствами, чтобы избежать необходимости использования справочной подтаблицы, замедляющей процессы записи и чтения.

Сегодня совершенно случайно встретила... догадайтесь кого? Самого сами знаете кого!
:)


Василий Стрельников

Он все такой же позитивый человек, с отличным чувством юмора и невероятно молодыми глазами и душой. Я категорически счастлива, что мы живем с этим человеком в одно время. Спасибо, Вася, твои передачи, твой голос в моем сердце с детства и навсегда :) Ты - супер!

Рекомендую
http://zhgun.livejournal.com/

Промо на злободневную тему.


© zhgun

Фильм поражает и рвет башню :)

Другие названия: Коллекторы, Конфискаторы, Потрошители, REPO MEN (2010).

Это новый жанр и новый стиль: ультрациничный комедийный научнофантастический триллер на остросоциальную медикоюридическую тему про кредиты на искуственные человеческие органы.

IMDB (english):

http://www.imdb.com/title/tt1053424/

OST (саунд треки фильма) - заслуживают отдельного восхищения :)

http://tfile.ru/forum/viewtopic.php?t=303844

Афиша: Описание, рецензии, расписание, трейлеры, кадры:

http://www.afisha.ru/movie/198020/

Русский трейлер.

Моим коллегам-девелоперам посвящается :)

Целый день ковыряю маны и папирусы на мелкософте. Вот спрашивается, зачем нужен вообще SQL Server 2005, если по умолчанию у него ОТКЛЮЧЕНА функция работы в сети? Вы где-нибудь видели чтобы на сервере работали ЛОКАЛЬНО? Причем ни в одном мне по возникающим ошибкам об этом не сказано. Вот ведь куда зарыли...

1. Configuration Manager - включить сперва TCP/IP протокол :)) да-да, он выключен по дефолту - НА СЕРВЕРЕ!


2. Теперь сюда, выбираем верхний пункт


3. тут в сетевых настройках Database Engine надо РАЗРЕШИТЬ подключения из сети с использованием этого протокола :))


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


Чудеса совместимости или не верь своим глазам :)
Убей пол дня и потом пол дня смейся еще над тем же :)

Интересная игра - УНО.



Читать описание и правила игры
Кому интересно поиграть в новый год, у кого есть дома лазерный принтер, ножницы, четыре разноцветных маркера и плотная бумага (либо, обложки глянцевых журналов и клей), тот может скачать этот макет карт УНО 70х50мм.

Макет в формате TIFF, LZW компрессия, со слоями в ZIP, монохромный (для раскрашивания маркерами), 1.7 Мб. Для получения полного набора карт потребуется распечатать данный макет на 8 листах А4.

Макет, TIFF/LZW(Layers:ZIP), A4, 1.7Mb

P.S. Благодарю ice_3000 за открытие :)

-- Кто говорит?
-- aksy_lis!

Ура, сегодня 24 декабря и в моем доме раздался первый телефонный звонок. Утром пришли телефонисты, посмеялись над моим котом :) , пришли в откровенное удивление от того, что женщина способна смонтировать на стене телефонную розетку, а потом ушли чего-то втыкать.
Оказывается, телефонная разводная коробка находится этажом ниже, а там металлическая дверь на этаже. Уж не знаю как они в итоге туда попали, но через пять минут телефонная "лапша" в моей квартире начала шевелиться как живая и откуда-то снизу закричали "готово!".
В торжественной обстановке мне объявили номер моего стационарного телефона и сказали что жить я теперь буду долго и счастливо, и через 10 минут мне позвонили для проверки связи.
Первые впечатления от выбранного аппарата.
Звук чистый, немного завышены высокие частоты. База тоже звонит при входящем звонке. Автоответчик работает отлично. АОН не работает, видимо надо подключать за деньги. В целом, меня все устраивает, и, даже радует. За 1200 рублей по-моему отличный вариант.
Теперь по плану - нормальный общечеловеческий интернет.

Друзья,
посоветуйте хороший радио-телефон для дома со следующими характеристиками:
1. Нормальный живучий аккумулятор, чтобы можно было оставлять на базе и не было перезаряда со скорой смертью батарейки (следовательно это, как я понимаю, НЕ панасоник)
2. Отсутствие глюков по функциональной части (без шумов, эха, скрежета пластика в эфир)
3. Цена до 4 тыщ рублей.
4. АОН
5. Телефонная книга
6. Возможность крепления базы на стену

Если у кого есть опыт использования таких прибамбасов - буду рада поболтать.

UPDATE 23/12/2009

По отзывам наиболее безглючными кажутся модели SIEMENS. По дизайну и функциям - серия SL, в которой так же база и зарядные кредлы можно располагать отдельно). По энергоэкономичности батареи - модели C380 и C385 (с автоответчиком).


Однако, я решила выбрать вот этот телефон. Он случайно попался мне по пути и оказался более подходящим.
Motorola D812
http://market.yandex.ru/model.xml?hid=91464&modelid=1599684
только в белом цвете:
http://mdata.yandex.ru/i?path=b0221162813__w2.jpg
Ход мысли был следующий:
1. Я поняла, что для меня все-таки важно установить базу на стену и причем отдельно от зарядного кредла, чтобы база была в центре квартиры (у меня это коридор), а трубки были бы в комнатах.
2. Две трубки. У меня как раз две комнаты и я постоянно перемещаюсь по дому, когда разговариваю по телефону и могу потом забыть где я оставила одну из трубок, поэтому могу взять вторую и говорить по ней.
3. Опять же, появляется возможность разговаривать между трубками. Я могу выйти на улицу ковыряться в машине и позвонить домой, попросить вынести какой-нибудь ключ "на пятнадцать" - у меня бывали такие потребности. Можно говорить втроем и перебрасывать звонки из одной комнаты в другую. Весело.
4. Аккумуляторные батареи в этих трубках - обычные мизинчиковые. Даже если они умрут, я могу их заменить за небольшую цену и просто их найти.
5. Автоответчик на русском языке, с возможностью дистанционного прослушивания сообщений (с работы).
6. Цена в Ашане вчера была 1200 рублей (это ниже средней цены в интернете на 550 рублей). А за такую цену купить по сути три устройства (базу и две трубки) - это вполне интересно.

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

UPDATE 10:00

Хочу добавить, что ковыряясь с телефоном с раннего утра, нашла много приятных фич, о которых не подозревала при покупке.
* в базу можно вставить SIM-карту из своего мобильного телефона и скопировать из нее телефоны в память своего нового стационарного телефона. считаю это очень интересной функцией для людей, которые до этого пользовались только мобильниками.
* в режиме ожидания дисплеи трубок слабо светятся и на них отображаются аналоговые часы. за счет этого трубки видно в темноте и сразу понятно сколько время. теперь часы покупать не надо :)
* база тоже звонит при входящем звонке, правда одной из четырех собственных 8-битных мелодий :)
* можно установить приоритет звонка между трубками, т.е. какая будет звонить раньше, если например одна из трубок находится в спальне, ей можно задать низкий приоритет, чтобы на звонок мог ответить человек, который не спит и находится в другой комнате