Friday, 11 September 2009

andrzejn: (South Park)
Экселенц полез в боковой ящик стола, где всякий нормальный человек держит диски и флэшки, и извлёк оттуда некий громоздкий картонный предмет синего цвета, завёрнутый в старинный полиэтиленовый мешок, схваченный наперекрест двумя тонкими чёрными резинками. Его украшали две большие буквы: О и З (или это был номер 03?), а ниже - стилизованный иероглиф "сандзю".

Название предмета я поначалу вспомнил из Стругацких: "заккурапия", что в точном переводе означает - "вместилище документов". И только когда Экселенц водрузил это вместилище на стол перед собой и сложил на нем длинные узловатые пальцы, у меня вырвалось:

- Фолдер!

Первым моим побуждением было засунуть всю эту груду в сканер, но я, разумеется, вовремя спохватился.

- Не отвлекайся, - строго сказал он, - слушай внимательно. Это текст моего нового романа. Кстати, сканировать и выкладывать в сеть запрещаю.
andrzejn: (Default)
Давным-давно, когда Windows и SQL серверов ещё не было, базы данных уже были, и в них уже были индексы (даже в таких экзотических, как Btrieve, где не было полей). В те времена программисты сами думали о том, какие индексы им нужны для наилучшего быстродействия, и сами явно вызывали поиск каждой записи по тому или иному индексу.

Потом появились SQL сервера, которые научились сами составлять планы исполнения запросов и подбирать под них подходящие индексы из наличных. Правда, поначалу они делали это плохо - им часто приходилось подсказывать, какой индекс лучше брать. И индексы по-прежнему надо было придумывать и создавать явными командами.

Потом в дополнение к индексам появились статистики, и сервера стали составлять всё лучшие планы запросов, пока не превзошли в этом абсолютное большинство людей. Но индексы и статистики по-преэнему надо было сочинять самим.

Потом практически во все сервера добавили утилиты-оптимизаторы, которые анализировали предложенные запросы на наличных данных и, зная тайные алгоритмы планировщика, подсказывали, какие индексы и статистики надо ещё создать, чтобы повысить скорость. Но подбирать список запросов, просматривать список советов и запускать его на исполнение по-прежнему нужно вручную.

Следующий очевидный шаг - чтобы SQL сервера сами анализировали поступающие запросы в ходе обычной повседневной работы, сами создавали новые индексы и статистики, когда надо, а устаревшие - удаляли. А потом и вовсе отобрать эту возможность у программистов. Любопытно, это где-нибудь уже сделали?
andrzejn: (Curious)
[livejournal.com profile] rikki_t_tavi напоминает, как следует бороться с перфекционизмом: делать хоть что-нибудь, что сейчас легко, понемножку, по кусочку. Будет медленно и неидеально - но будет хоть что-нибудь. Я тоже об этом писал, называл муравьиной тактикой, даже дважды. Это понятно, это работает.

Проблемы начинаются, когда хоть что-нибудь и по кусочку - категорически недостаточно. Просто потому что нужно всё и в срок, а если меньше и позже, то уже не взлетит, не заработает, никому не понадобится...

Для такой ситуации я решения не знаю. То есть знаю - отпустить шкурку в автопилот - но это работает недолго, а обходится потом дорого. Постоянно так жить нельзя.

Путь в тысячу ли начинается с одного шага. А потом остаётся только прошагать без малого тысячу ли. Об этом я тоже писал уже дважды, а это - третий раз...

Profile

andrzejn: (Default)
Андрій Новосьолов

May 2025

M T W T F S S
    1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22232425
262728293031 

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Thursday, 22 May 2025 17:28
Powered by Dreamwidth Studios