Практика 11 ноября

Разминка


У вас есть таблицы A(id) и B(a_id, b). Какие из этих запросов найдут те A.id, которые НЕ упоминаются в B.a_id ?

1. SELECT id FROM A WHERE id NOT IN (SELECT a_id FROM B)
2. SELECT id FROM A EXCEPT SELECT a_id AS id FROM B
3. SELECT id FROM A LEFT OUTER JOIN B ON (A.id = B.a_id) 
   WHERE B.a_id IS NULL

Слайды

(полноэкранные)

Идея курсовой, а то и диплома, для любителей карт и crowdsourcing

У меня есть слабость к (географическим) картам, и я в свободное время вожусь с открытым картографическим проектом OpenStreetMap. Суть его в том, что пользователи несколькими способами рисуют карты, нанося дороги, реки, дома, достопримечательности и так далее, а результат под свободной лицензией принадлежит всему миру. Его можно например закачать на навигатор и использовать для ориентирования.



Помимо всего прочего, на карту можно наносить Points Of Interest -- магазины, аптеки, рестораны и прочие заведения, которые могут быть людям интересны. У нас в России с такими заведениями есть проблема: они быстро исчезают и заменяются другими. Магазин, просуществовавший три года, можно считать старожилом.

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

Кстати о контактеге. Туда-то все топают каждый день и порой даже оттуда не вылезают. И более того, многие услужливо заносят туда кое-какую географическую информацию: кто точное место жительства, кто неточное, кто название ВУЗа или места работы. По этой информации можно понять, в каком районе человек может быть если не экспертом по части заведений, но по крайней мере может по дороге домой что-нибудь посмотреть.

Соответственно идея инженерная: сделать приложение для контактега, которое будет раз в день (иначе надоест) спрашивать пользователя "скажи, кафе 'Сачок' ещё работает или уже склеило ласты?". И две кнопки -- "да" и "нет". Ответ нужно записывать где-нибудь на server-side и потом обрабатывать. Если 10 человек скажут что "Сачок" накрылся, значит он наверное и правда накрылся и можно уведомить об этом смотрителя Петродворцового района на OpenStreetMaps/Bugs.

А идея математическая такая: я конечно не буду счастлив отвечать на вопросы про Купчино, где я почти никогда не бываю и даже про те места, где я бываю, я не буду счастлив отвечать 10 раз подряд. Нужна такая модель, которая будет разумно составлять пары (пользователь, POI) и показывать их. Учитывать географические данные пользователя. Учитывать как часто его уже спрашивали об этой точке. Учитывать насколько устарели данные об этой точке. Учитывать то что часто спрашивать нельзя и выбирать только наиболее актуальные вопросы.

Если кому интересно этим заняться, под моим руководством или под чьим-то ещё, feel free.

Вот как нужно работать в университете

http://googleappengine.blogspot.com/2010/10/research-project-appscale-at-university.html

Коротко содержание: ребята плакали-плакали что у них нет подходящей кластерной инфраструктуры для их проектов, а потом посмотрели на гугловский App Engine, им понравилось и они за два года сделали себе такой же, но с открытым кодом. И теперь счастливы. Один доцент и несколько аспирантов и студентов. Безо всяких там Интелов. Что-то мне подсказывает, что с трудоустройством у них проблем не будет.

А у нас, мать-перемать, кто только не крутится вокруг матмеха, а толком даже расписания нормального на сайте нет. Не стыдно?

Практика 28 октября

Разминка

Вопрос 1. Что получится в результате выполнения запроса?

Table1

a   b   c

---------

1   1   1

2   3   4

1   1   7

2   3   8

SELECT * FROM Table1 GROUP BY a

1. Будет напечатана вся таблица 
2. Для каждого значения "a" посчитают сумму в столбцах "b" и "c"
3. Запрос не выполнится потому что не используются агрегатные функции
4. Запрос не выполнится потому что в SELECT используются недопустимые в данном случае атрибуты

Вопрос 2. А с этим запросом и такой же таблицей что будет?

SELECT a, SUM(b) AS foo FROM Table1 GROUP BY a

1.
a foo
------
1 2
2 6

2.
a foo
------
1 2
2 2

Слайды
полноэкранные

Дни Суперкомпьютерных технологий в офисе Intel

Звучит громко, в реальности наверное будет поскромнее, но наверное всё равно интересно. Обратите внимание что требуется регистрация.

Анонс

Практика 14 октября

Разминка


Вопрос 1. Сколько строк будет в результате SELECT'а?

CREATE TABLE Автомобиль(

    рег_номер CHAR(6) PRIMARY KEY, марка VARCHAR(20))

INSERT INTO Автомобиль (рег_номер, марка)

  VALUES ('м000ск', 'Субару')

INSERT INTO Автомобиль (рег_номер, марка)

  VALUES ('м001ск', 'Cубару')

INSERT INTO Автомобиль (рег_номер, марка)

  VALUES ('м002ск', 'Subaru')

SELECT * FROM Автомобиль  WHERE марка = 'Субару'

Вопрос 2. Сколько будет в результате выполнения запроса если в таблице N строк?

CREATE TABLE Foobar (id INT PRIMARY KEY, value INT)

SELECT * FROM Foobar f1 JOIN Foobar f2 ON (f1.id = f2.id)

1. 0 строк
2. N строк
3. N*N строк
4. Заранее неизвестно
5. Запрос не выполнится

Слайды

Разминка

Вопрос 1.

Что произойдет в результате выполнения скрипта:


CREATE TABLE A (
  a1 INT, a2 VARCHAR, a3 NUMERIC, UNIQUE (a1, a2))


CREATE TABLE B (
  b1 VARCHAR, b2 NUMERIC, b3 INT,
  FOREIGN KEY (b1, b2) REFERENCES A(a2,a3))

1. Скрипт не выполнится, потому что внешний ключ не может быть составным
2. Скрипт не выполнится, потому что ссылочные атрибуты не являются ключом
3. Скрипт не выполнится, потому что имена ссылающихся и ссылочных атрибутов разные
4. Скрипт выполнится без ошибок

Вопрос 2.

Вы делаете связь многие-ко-многим между товарами и поставщиками у которой есть собственный атрибут, например, цена данного товара у данного поставщика. Вы хотите чтоб цена была уникальна для пары (товар, поставщик). Чего не хватает в этом операторе?


CREATE TABLE Goods_Supplier(
  goods_id INT FOREIGN KEY REFERECES Goods,
  supplier_id INT FOREIGN KEY REFERENCES Supplier,
  price NUMERIC (10, 2) CHECK (price >= 0))

1. Да вроде всё на месте
2. Ограничения UNIQUE для цены
3. Ограничения UNIQUE для каждого из внешних ключей
4. Ограничения UNIQUE для пары внешних ключей
5. Ограничения UNIQUE для всей тройки атрибутов

Слайды

Смотреть здесь