2017-09-10 Uninformed Search.md
Различия
Здесь показаны различия между двумя версиями данной страницы.
| Следующая версия | Предыдущая версия | ||
|
блоги_и_отзывы:krat_nikolay:2017-09-10_uninformed_search.md [04.09.2018 07:15] 127.0.0.1 внешнее изменение |
блоги_и_отзывы:krat_nikolay:2017-09-10_uninformed_search.md [20.05.2019 15:18] (текущий) |
||
|---|---|---|---|
| Строка 13: | Строка 13: | ||
| Оставшиеся поиски по критерию стоимости и двунаправленный поиск достаточно специфичны, чтобы как-то обобщить их на повседневную работу с кодом. Хотя аналогом двунаправленного поиска (с ручным управлением) можно считать операцию join, знакомую всем по реляционным БД. Одинарные join могут быть тривиальными, но для решения множественных join нескольких таблиц, движок реляционной БД может, на основании своих знаний о «графе» (приблизительные размеры таблиц, условия фильтрации, объем оперативной памяти), выбрать места склеивания таблиц и порядок склеивания, чтобы результирующий подграф поиска был минимальным. И хоть такие сложные вещи, как executor запросов в БД, редко приходится писать, бывает полезно искать пути поиска решения с разных сторон. Например, при расчете начисления абон.платы пользователям, заранее загрузить в кеш все тарифы и вычислить их сумму, если это возможно, а не делать это каждый раз. Это же касается замены кучи запросов к БД при генерации страницы в каком-нибудь веб фреймворке одним большим запросом. Не делайте кучи подзапросов… | Оставшиеся поиски по критерию стоимости и двунаправленный поиск достаточно специфичны, чтобы как-то обобщить их на повседневную работу с кодом. Хотя аналогом двунаправленного поиска (с ручным управлением) можно считать операцию join, знакомую всем по реляционным БД. Одинарные join могут быть тривиальными, но для решения множественных join нескольких таблиц, движок реляционной БД может, на основании своих знаний о «графе» (приблизительные размеры таблиц, условия фильтрации, объем оперативной памяти), выбрать места склеивания таблиц и порядок склеивания, чтобы результирующий подграф поиска был минимальным. И хоть такие сложные вещи, как executor запросов в БД, редко приходится писать, бывает полезно искать пути поиска решения с разных сторон. Например, при расчете начисления абон.платы пользователям, заранее загрузить в кеш все тарифы и вычислить их сумму, если это возможно, а не делать это каждый раз. Это же касается замены кучи запросов к БД при генерации страницы в каком-нибудь веб фреймворке одним большим запросом. Не делайте кучи подзапросов… | ||
| - | |||
| - | ~~OWNERAPPROVE~~ | ||
127.0.0.1