Лекции "Анализ поисковых запросов", читает Павел Браславский, яндексоид из Екатеринбурга, в питерском CS клубе при ПОМИ. Вход свободный, возможно будет видеотрансляция. Первые две -- в субботу 27 ноября, следующие две в декабре.
http://logic.pdmi.ras.ru/csclub/searchqueryanalysis
От себя добавлю что анализ запросов -- очень интересная тема как для математиков -- любителей поковыряться во всякого рода статистике, так и для инженеров, нагло паразитирующих на исследованиях математиков и подстраивающих алгоритмы поиска и ранжирования в соответствии с их выводами.
25 ноября 2010
Практика 25 ноября
Разминка
Какие из этих запросов найдут в таблице Employee(name, salary) имена сотрудников с максимальной зарплатой и собственно максимальную зарплату?
Какие из этих запросов найдут в таблице Employee(name, salary) имена сотрудников с максимальной зарплатой и собственно максимальную зарплату?
- SELECT name, MAX(salary) FROM Employee
- SELECT E1.name, E1.salary
FROM Employee E1 LEFT OUTER JOIN Employee E2 ON (E1.salary < E2.salary)
WHERE E2.name IS NULL - SELECT name, MAX(salary) FROM Employee
GROUP BY name - SELECT name, salary FROM Employee WHERE salary = (SELECT MAX(salary) FROM Employee)
18 ноября 2010
Практика 18 ноября
Разминка
Вы хотите просуммировать суммы выплаченных вашим сотрудникам зарплат за год и вывести в результат табличку с ФИО и суммой. Какие из этих запросов сделают то что вы хотите?
В таблице Payments есть поля employee_id (id сотрудника), name (ФИО сотрудника), month (месяц выплаты) и payment (сумма выплаты).
Слайды
Вы хотите просуммировать суммы выплаченных вашим сотрудникам зарплат за год и вывести в результат табличку с ФИО и суммой. Какие из этих запросов сделают то что вы хотите?
В таблице Payments есть поля employee_id (id сотрудника), name (ФИО сотрудника), month (месяц выплаты) и payment (сумма выплаты).
- SELECT name, SUM(payment) FROM Payments GROUP BY employee_id
- SELECT name, SUM(payment) FROM Payments GROUP BY employee_id, name
- SELECT p2.name, p1.sum_payment FROM
(SELECT employee_id, SUM(payment) AS sum_payment
FROM Payments GROUP BY employee_id) AS p1
JOIN
Payments p2 ON (p1.employee_id = p2.employee_id)
Слайды
16 ноября 2010
Лекция Джеффа Дина в Стенфорде
Тем кто интересуется поисковиками и понимает по-английски будет интересно послушать лекцию одного из лучших гугловских инженеров. В аудитории якобы было столько народу, что Дональду Кнуту пришлось сидеть на полу.
http://doubleclix.wordpress.com/2010/11/11/google-a-study-in-scalability-and-a-little-systems-horse-sense/
Там есть и видео в формате MMSH который на windows наверное будет играться сам, а на Linux потребует установки, например, vlc.
Не понимаешь английский? Продолжай косить его в универе.
http://doubleclix.wordpress.com/2010/11/11/google-a-study-in-scalability-and-a-little-systems-horse-sense/
Там есть и видео в формате MMSH который на windows наверное будет играться сам, а на Linux потребует установки, например, vlc.
Не понимаешь английский? Продолжай косить его в универе.
11 ноября 2010
Практика 11 ноября
Разминка
У вас есть таблицы A(id) и B(a_id, b). Какие из этих запросов найдут те A.id, которые НЕ упоминаются в B.a_id ?
Слайды
(полноэкранные)
У вас есть таблицы A(id) и B(a_id, b). Какие из этих запросов найдут те A.id, которые НЕ упоминаются в B.a_id ?
- SELECT id FROM A WHERE id NOT IN (SELECT a_id FROM B)
- SELECT id FROM A EXCEPT SELECT a_id AS id FROM B
- SELECT id FROM A LEFT OUTER JOIN B ON (A.id = B.a_id)
WHERE B.a_id IS NULL
Слайды
(полноэкранные)
09 ноября 2010
Идея курсовой, а то и диплома, для любителей карт и crowdsourcing
У меня есть слабость к (географическим) картам, и я в свободное время вожусь с открытым картографическим проектом OpenStreetMap. Суть его в том, что пользователи несколькими способами рисуют карты, нанося дороги, реки, дома, достопримечательности и так далее, а результат под свободной лицензией принадлежит всему миру. Его можно например закачать на навигатор и использовать для ориентирования.
Помимо всего прочего, на карту можно наносить Points Of Interest -- магазины, аптеки, рестораны и прочие заведения, которые могут быть людям интересны. У нас в России с такими заведениями есть проблема: они быстро исчезают и заменяются другими. Магазин, просуществовавший три года, можно считать старожилом.
Для того чтоб информация на карте была постоянно свежей, нужно её постоянно поддерживать. Нужно добавлять новые заведения и сообщать об исчезновении старых. Для этого даже заведён специальный сайт OpenStreetBugs, на котором несложно сообщить об изменениях, но всё равно нормальному человеку нужно на этот сайт хотя бы заходить. Я с трудом представляю себе толпу энтузиастов, каждый день топающую на OpenStreetBugs вместо контактега или жежешечки.
Кстати о контактеге. Туда-то все топают каждый день и порой даже оттуда не вылезают. И более того, многие услужливо заносят туда кое-какую географическую информацию: кто точное место жительства, кто неточное, кто название ВУЗа или места работы. По этой информации можно понять, в каком районе человек может быть если не экспертом по части заведений, но по крайней мере может по дороге домой что-нибудь посмотреть.
Соответственно идея инженерная: сделать приложение для контактега, которое будет раз в день (иначе надоест) спрашивать пользователя "скажи, кафе 'Сачок' ещё работает или уже склеило ласты?". И две кнопки -- "да" и "нет". Ответ нужно записывать где-нибудь на server-side и потом обрабатывать. Если 10 человек скажут что "Сачок" накрылся, значит он наверное и правда накрылся и можно уведомить об этом смотрителя Петродворцового района на OpenStreetMaps/Bugs.
А идея математическая такая: я конечно не буду счастлив отвечать на вопросы про Купчино, где я почти никогда не бываю и даже про те места, где я бываю, я не буду счастлив отвечать 10 раз подряд. Нужна такая модель, которая будет разумно составлять пары (пользователь, POI) и показывать их. Учитывать географические данные пользователя. Учитывать как часто его уже спрашивали об этой точке. Учитывать насколько устарели данные об этой точке. Учитывать то что часто спрашивать нельзя и выбирать только наиболее актуальные вопросы.
Если кому интересно этим заняться, под моим руководством или под чьим-то ещё, feel free.
Помимо всего прочего, на карту можно наносить Points Of Interest -- магазины, аптеки, рестораны и прочие заведения, которые могут быть людям интересны. У нас в России с такими заведениями есть проблема: они быстро исчезают и заменяются другими. Магазин, просуществовавший три года, можно считать старожилом.
Для того чтоб информация на карте была постоянно свежей, нужно её постоянно поддерживать. Нужно добавлять новые заведения и сообщать об исчезновении старых. Для этого даже заведён специальный сайт OpenStreetBugs, на котором несложно сообщить об изменениях, но всё равно нормальному человеку нужно на этот сайт хотя бы заходить. Я с трудом представляю себе толпу энтузиастов, каждый день топающую на OpenStreetBugs вместо контактега или жежешечки.
Кстати о контактеге. Туда-то все топают каждый день и порой даже оттуда не вылезают. И более того, многие услужливо заносят туда кое-какую географическую информацию: кто точное место жительства, кто неточное, кто название ВУЗа или места работы. По этой информации можно понять, в каком районе человек может быть если не экспертом по части заведений, но по крайней мере может по дороге домой что-нибудь посмотреть.
Соответственно идея инженерная: сделать приложение для контактега, которое будет раз в день (иначе надоест) спрашивать пользователя "скажи, кафе 'Сачок' ещё работает или уже склеило ласты?". И две кнопки -- "да" и "нет". Ответ нужно записывать где-нибудь на server-side и потом обрабатывать. Если 10 человек скажут что "Сачок" накрылся, значит он наверное и правда накрылся и можно уведомить об этом смотрителя Петродворцового района на OpenStreetMaps/Bugs.
А идея математическая такая: я конечно не буду счастлив отвечать на вопросы про Купчино, где я почти никогда не бываю и даже про те места, где я бываю, я не буду счастлив отвечать 10 раз подряд. Нужна такая модель, которая будет разумно составлять пары (пользователь, POI) и показывать их. Учитывать географические данные пользователя. Учитывать как часто его уже спрашивали об этой точке. Учитывать насколько устарели данные об этой точке. Учитывать то что часто спрашивать нельзя и выбирать только наиболее актуальные вопросы.
Если кому интересно этим заняться, под моим руководством или под чьим-то ещё, feel free.
Подписаться на:
Сообщения (Atom)