По поводу сортировки по модулю разницы: я выше уже писал, что «если передан id первой или последней фотки, то результат не будет удовлетворять условию».
Где image.is_pulbished = 1?
LEFT JOIN здесь не нужен, здесь достаточно INNER JOIN.
У до сих пор есть ящик на mail.ru, где первым символом является подчеркивание — зарегал еще тогда, когда это было можно.
Как-то вроде работает (не знаю, давненько не проверял вообще), но иногда бывали проблемы с почтой.
Да, одним запросом, но ограничения на использование возможностей СУБД состоит в том, что решение должно быть совместимым с Oracle 11g, SQL Server 2008 или DB2 9.5.
Так не выйдет. N — переменная, которая передается в запрос, то есть запрос должен быть универсальным. Ограничений на использование возможностей БД нет.
Правда есть косяк, я тут посмотрел получше, по условию задачи (pdf-файлик), там не говорится про MySQL:
«Contestants may use any database technology at their disposal, but the submitted solutions should be compatible with at least one of the following database tech-nologies: Oracle 11g for Windows, SQL Server 2008, and DB2 9.5 for Windows».
То есть решение должно может быть написано для любой СУБД, но быть совместимым с Oracle 11g, SQL Server 2008 или DB2 9.5.
Не так давно мне попалась одна интересная и невероятно сложная задача (pdf) по SQL:
Есть 20-гранная игральная кость с числами на ней (числа не от 1 до 20, они случайны и не повторяются).
Есть таблица, содержащая все числа с кости и вероятности их выпадения.
Надо написать SQL-запрос, который выдаст вероятности выпадения каждой из возможных сумм чисел при N бросках (N — переменная).
А вообще, по-хорошему, если сделать вместо is_main_foto у фотографии main_photo_id и first_photo_id у галереи, то огромной части всего этого SQL-геморроя можно было бы избежать.
Первое (громоздко вышло, выше было решение, которое мне самому больше понравилось):
select g.id, g.title, i.id, i.title
from photo_category c
inner join photo_gallery g
on g.c_id = c.id
inner join photo_image i
on i.g_id = g.id
inner join photo_image i_1
on i_1.g_id = i.g_id
where (i.is_main_foto = 1
or i.is_published = 1)
and i_1.is_main_foto = 0
and i_1.is_published = 1
and g.is_published = 1
and c.is_published = 1
and c.id = :id
group by g.id, g.title, i.id, i.title
having count(i.id) > 1
or (count(i.id) <= 1
and count(i_1.id) > 0)
order by
g.ordi,
i.ordi;
Второе (без юниона, но жесть, т.к. как я понял, надо выбрать и следующую, и предыдущую):
select
( select i.id
from photo_image i
where i.is_published = 1
and i.g_id = :g_id
and i.ordi < (select x.ordi from photo_image x where x.id = :id)
limit 1
) as prv,
( select i.id
from photo_image i
where i.is_published = 1
and i.g_id = :g_id
and i.ordi > (select x.ordi from photo_image x where x.id = :id)
limit 1
) as nxt;
select
lag(i.id, 1) over (order by ordi) prv,
lead(i.id, 1) over (order by ordi) nxt
from photo_image i
where i.is_pubilshed = 1
and i.g_id = :g_id
and i.id = :id;
Похожим образом, кстати, реализован persistence в Google DataStore. Класс и его свойства содержат аннотации, указывающие как что хранить.
Мне как закостенелому SQL-щику это кажестя странным, хотя я понимаю, что с точки зрения нормальных разработчиков так лучше :-)
Я всегда думал, что оптимизировать код дешевле, чем покупать новое оборудование.
применительно к ситуации с обновлением одной строки, file_put_contents() будет хорошо масштабироваться ровно до тех пор пока размер файла не превышает размер блока ФС, а затем начнет работать все медленнее.
Где image.is_pulbished = 1?
LEFT JOIN здесь не нужен, здесь достаточно INNER JOIN.
Как-то вроде работает (не знаю, давненько не проверял вообще), но иногда бывали проблемы с почтой.
Из всех имеющихся в наличии СУБД у меня это сработало только в MySQL.
В Oracle и MS SQL это не работает. Есть кто с PostgreSQL?
Иначе их можно обработать только в конструкции WHERE запроса уровнем выше, что я уже в данном случае нахожу излишним.
Правда есть косяк, я тут посмотрел получше, по условию задачи (pdf-файлик), там не говорится про MySQL:
«Contestants may use any database technology at their disposal, but the submitted solutions should be compatible with at least one of the following database tech-nologies: Oracle 11g for Windows, SQL Server 2008, and DB2 9.5 for Windows».
То есть решение должно может быть написано для любой СУБД, но быть совместимым с Oracle 11g, SQL Server 2008 или DB2 9.5.
Есть 20-гранная игральная кость с числами на ней (числа не от 1 до 20, они случайны и не повторяются).
Есть таблица, содержащая все числа с кости и вероятности их выпадения.
Надо написать SQL-запрос, который выдаст вероятности выпадения каждой из возможных сумм чисел при N бросках (N — переменная).
В оракле гораздо проще, но по условию нельзя :-(
Мне как закостенелому SQL-щику это кажестя странным, хотя я понимаю, что с точки зрения нормальных разработчиков так лучше :-)
применительно к ситуации с обновлением одной строки, file_put_contents() будет хорошо масштабироваться ровно до тех пор пока размер файла не превышает размер блока ФС, а затем начнет работать все медленнее.