ReSQL.ru
     
powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / MySQL [игнор отключен] [закрыт для гостей] / 2 Хрен
17 сообщений из 17, страница 1 из 1
2 Хрен
    #33108552
Фотография Berkut
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Berkut
Участник
Пару слов по поводу "задачки"...

Постараюсь объяснить почему мне понравилось именно данное решение. :)

* во-первых, оно написано на стандартном SQL и будет работать везде, где есть min(), group by & distinct

* во-вторых, если вы смотрели топик, то могли заметить, что там было предложенно очень много изящных решений с особенностями конкретной СУБД

* а в-третьих, в посте есть такая фраза ИМХО , пожалуй самое оригинальное решение

Что касается использования HANDLER я так и не понял чем же он лучше в данном контексте, кроме как
MySQL Manual :: HANDLER
\x7f Он быстрее чем SELECT, потому что:
Выделенный код обработчика таблиц создается в потоке по вызову HANDLER open.

Меньше синтаксического анализа.

Нет нагрузки на оптимизацию и проверку.

Таблицу не нужно блокировать между запросами.

Этот интерфейс не обязан предоставлять целостный вид данных (скажем, грязное чтение допускается), что позволяет обработчику таблиц делать оптимизации которые SQL обычно не допускает.
\x7f Гораздо легче переносить на MySQL приложения, которые используют интерфейс, подобный ISAM.
\x7f Такой интерфейс позволяет просматривать базу данных способом, который не так легко (или в некоторых случаях и вовсе невозможно) реализовать с помощью SQL. Интерфейс HANDLER является более естественным способом получить данные, когда приходится иметь дело с интерактивными пользовательскими приложениями.



Вовсе не против и рад буду увидеть ваш вариант решения. :)
...
Рейтинг: 0 / 0
09.06.2005, 09:46
| Ответить | Цитировать | Написать  
2 Хрен
    #33110554
Astron
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Astron
Гость
Мне бы вот тоже хотелось. Решением головоломок на SQL я немного интересуюсь (не имея в виду темы "помогите составить запрос", а именно головоломок). Так вот по поводу HANDLER - действительно не оно, потому как в условии физическое расположение записей в файле данных не задано.
А ответа от г.Хрена дождаться будет непросто. Сценарий развития темы на этом форуме примерно такой -
1) Пишется вопрос
2) Даетcя ответ RTM. Этот ответ я сам могу давать причем на любой вопрос из любой области человеческой деятельности. ИМХО если уж решили послать человека в мануал, так хотя бы главу надо говорить...
3) Дается оригинальный ответ (не всегда, конечно, но бывает)
4) Появляется пост г.Хрена "...хрен оно так ...."
5) Молчание г.Хрена на попытки подискутировать - игнор аргументов.
...
Рейтинг: 0 / 0
09.06.2005, 20:32
| Ответить | Цитировать | Написать  
2 Хрен
    #33110598
Фотография Хрен
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Хрен
Участник
Astron Так вот по поводу HANDLER - действительно не оно, потому как в условии физическое расположение записей в файле данных не задано.


handler никак не связан с физическим расположением записей в файле данных.

А ответа от г.Хрена дождаться будет непросто. Сценарий развития темы на этом форуме примерно такой -
1) Пишется вопрос
2) Даетcя ответ RTM. Этот ответ я сам могу давать причем на любой вопрос из любой области человеческой деятельности. ИМХО если уж решили послать человека в мануал, так хотя бы главу надо говорить...
3) Дается оригинальный ответ (не всегда, конечно, но бывает)
4) Появляется пост г.Хрена "...хрен оно так ...."
5) Молчание г.Хрена на попытки подискутировать - игнор аргументов.

Ну чтож, раз я вижу тут личный наезд, на этот раз я отвечу.
1) я не имею возможности (и желания) постоянно торчать на форуме.
2) Я не обязан заниматься просветительской работой. Где именно посмотреть я наводку дал, судя по Вашему ответу - вы не очень и читали.
3) Я имею полное право игнорировать обсуждение, если считаю что оно пошло по кругу или перестало представлять для меня интерес.

Теперь по поводу handler. итак исходная задача:
"Как найти предыдущую и последующие записи в таблице для заданной при условии что последовательность идентификаторов (ID записей) не является непрерывной?"

по вашему примеру:

Код: plaintext
1.
2.
3.
4.
5.
-- создаем тестовую табличку
create table test (
 id int not null auto_increment,
 info char not null,
 primary key(id));

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

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
insert into test values ( 1 ,'A'),( 4 ,'D'),( 5 ,'E'),( 6 ,'F'),( 9 ,'X'),( 11 ,'Z');

mysql> select * from test;
+----+------+
| id | info |
+----+------+
|   1  | A    |
|   4  | D    |
|   5  | E    |
|   6  | F    |
|   9  | X    |
|  11  | Z    |
+----+------+
 6  rows in set ( 0 . 00  sec)

Открываем handler:

Код: plaintext
1.
handler test open;

И получаем две следующие записи после id = 4;

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
mysql> handler test read `primary` = ( 4 );
+----+------+
| id | info |
+----+------+
|   4  | D    |
+----+------+
 1  row in set ( 0 . 00  sec)

mysql> handler test read `primary` next;
+----+------+
| id | info |
+----+------+
|   5  | E    |
+----+------+
 1  row in set ( 0 . 00  sec)

mysql> handler test read `primary` next;
+----+------+
| id | info |
+----+------+
|   6  | F    |
+----+------+
 1  row in set ( 0 . 00  sec)

И две предыдущие:

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
mysql> handler test read `primary` = ( 4 );
+----+------+
| id | info |
+----+------+
|   4  | D    |
+----+------+
 1  row in set ( 0 . 00  sec)

mysql> handler test read `primary` prev;
+----+------+
| id | info |
+----+------+
|   1  | A    |
+----+------+
 1  row in set ( 0 . 00  sec)

mysql> handler test read `primary` prev;
Empty set ( 0 . 00  sec)

Видно, что последней записи просто нет (потому что запись с ID=4 нахолится слишком близко к началу таблицы если смотреть по первичному ключу)

И теперь осталось закрыть обработчик, чтобы не тратить ресурсы

Код: plaintext
1.
handler test close;


отличия от решения Berkut: Данные выбираются по индексному файлу, практически не нагружая сервер. Выборка в варианте Berkut происходит с subselects, которые всегда с трудом поддаются оптимизации и основательно грузят сервер.

То что Berkut's решение использует стандартный SQL это хорошо, но учитывая название темы (mysql cookroom) - на мой взгляд это не слишком большое достоинство.
...
Рейтинг: 0 / 0
09.06.2005, 21:19
| Ответить | Цитировать | Написать  
2 Хрен
    #33110706
Фотография Berkut
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Berkut
Участник
2 Хрен
Поначалу я решил, что ваше предложение использовать HANDLER относилось к решению "Интересной задачки", а не "Как найти предыдущую и последующие записи в таблице ...?".

То, что оно действительно не самое оптимальное в плане производительности, согласен. Собственно я это и указал в "примечаниях".
ХренДальше добавляем те же записи. Немного другим способом, потому что так, как это сделано в исходном сообщении (через union) на мой взгляд выглядит слишком непрофессионально.
По поводу "непрофессионального добавления" предлагаю не спорить, т.к. это был всего лишь тестовый вариант. :)

Хренотличия от решения Berkut: Данные выбираются по индексному файлу, практически не нагружая сервер. Выборка в варианте Berkut происходит с subselects, которые всегда с трудом поддаются оптимизации и основательно грузят сервер.

То что Berkut's решение использует стандартный SQL это хорошо, но учитывая название темы (mysql cookroom) - на мой взгляд это не слишком большое достоинство.
Данный пример был сделан на "скорую руку", и задача состояла именно в том, чтобы вытащить записи именно одним запросом.
...
Рейтинг: 0 / 0
10.06.2005, 00:09
| Ответить | Цитировать | Написать  
2 Хрен
    #33110709
Фотография Berkut
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Berkut
Участник
AstronМне бы вот тоже хотелось. Решением головоломок на SQL я немного интересуюсь
Astron, очень буду рад увидеть и ваши решения в Кук-Рум =)
Тем более, что вы немного интересуетесь .

P.S. Собственно говоря, предложение об открытии данной ветки и ее поддержки адресовалось всем. :)
...
Рейтинг: 0 / 0
10.06.2005, 00:14
| Ответить | Цитировать | Написать  
2 Хрен
    #33111006
sanek842
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
sanek842
Участник
можно так еще и тоже по индексам все
Код: plaintext
1.
2.
3.
4.
set @vid =  4 ;
select
 (select id from test where id<@vid limit  1  ) as prev_id,
 (select id from test where id>@vid limit  1  ) as next_id;
:)
...
Рейтинг: 0 / 0
10.06.2005, 09:49
| Ответить | Цитировать | Написать  
2 Хрен
    #33111104
Фотография Berkut
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Berkut
Участник
2 sanek842

Знаете в чем недостаток вашего решения? В том, что он не всегда работает правильно. :)

Например, есть такой набор данных:

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
+----+------+
| id | info |
+----+------+
|   1  | A    |
|   4  | D    |
|   5  | E    |
|   6  | F    |
|   9  | X    |
|  11  | Z    |
+----+------+

-- вот, что выводит 

set @vid =  9 ;
select
 (select id from test where id<@vid limit  1  ) as prev_id,
 (select id from test where id>@vid limit  1  ) as next_id;

+---------+---------+
| prev_id | next_id |
+---------+---------+
|        1  |       11  |
+---------+---------+
А причина как мне кажется в том, что вы смотрите именно по индексам, а надо выбирать ближайщие записи "сверху" и "снизу", т.е. min() и max().
...
Рейтинг: 0 / 0
10.06.2005, 10:24
| Ответить | Цитировать | Написать  
2 Хрен
    #33111132
sanek842
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
sanek842
Участник
а,ну да
наверно вот так нужно

set @vid = 4;
select
(select id from test where id<@vid order by id desc limit 1 ) as min_id,
(select id from test where id>@vid order by id asc limit 1 ) as max_id;

с учетом того что id в таблице идет с постоянным увеличением ( autoincrement ) то должно работать
...
Рейтинг: 0 / 0
10.06.2005, 10:31
| Ответить | Цитировать | Написать  
2 Хрен
    #33111160
sanek842
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
sanek842
Участник
Berkutзаписи "сверху" и "снизу", т.е. min() и max().
а вычислять миним. и макс. значения думаю будет лишним т.к. id это primary key , т.е. уникален и мы ненарвемся на случай ( в моем запросе ) где prev_id будет равен curr_id , скажем.
...
Рейтинг: 0 / 0
10.06.2005, 10:38
| Ответить | Цитировать | Написать  
2 Хрен
    #33111233
Фотография Berkut
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Berkut
Участник
2 sanek842
Кидайте ваше новое решение в MySQL "Cook Room" .
...
Рейтинг: 0 / 0
10.06.2005, 10:55
| Ответить | Цитировать | Написать  
2 Хрен
    #33111248
sanek842
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
sanek842
Участник
:)
...
Рейтинг: 0 / 0
10.06.2005, 11:00
| Ответить | Цитировать | Написать  
2 Хрен
    #33111277
Фотография Berkut
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Berkut
Участник
sanek842:)
Я серьезно! :)

А почему бы и нет!? :)
...
Рейтинг: 0 / 0
10.06.2005, 11:08
| Ответить | Цитировать | Написать  
2 Хрен
    #33111391
sanek842
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
sanek842
Участник
так сделай там ссылку на этот топик, тем более тут еще вариант с handler
:)
...
Рейтинг: 0 / 0
10.06.2005, 11:40
| Ответить | Цитировать | Написать  
2 Хрен
    #33111434
Фотография Berkut
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Berkut
Участник
Дело в том, что не хочется делать ссылки, т.к. не удобно будет потом искать информацию. ИМХО, идея как раз в том и состоит, чтобы собрать в одном месте "задачи" и их "решения".
...
Рейтинг: 0 / 0
10.06.2005, 11:51
| Ответить | Цитировать | Написать  
2 Хрен
    #33111446
sanek842
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
sanek842
Участник
ну, ладно
...
Рейтинг: 0 / 0
10.06.2005, 11:53
| Ответить | Цитировать | Написать  
2 Хрен
    #33111539
Astron
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Astron
Гость
Berkut 2 Хрен
Поначалу я решил, что ваше предложение использовать HANDLER относилось к решению "Интересной задачки", а не "Как найти предыдущую и последующие записи в таблице ...?".
Данный пример был сделан на "скорую руку", и задача состояла именно в том, чтобы вытащить записи именно одним запросом.

Да, я признаться тоже так подумал. Поэтому использование HANDLER показалось мне не совсем оправданным. С расположением записей - мой косяк, признаю, как говориться "вода кипит при 90 градусах - с прямым углом (primary key) перепутал"

2 Хрен
Уважаю как специалиста, честно, мой уровень будет пониже, но уж если отвечать в форум - то чтоб понятно было хотя бы автору топика. За наезд - извиняюсь, с вышесказанной оговоркой.
2 Berkut
Так я же совсем немного интересуюсь. Собственно, в поисках таких задачек я сюда и заглядываю. Если у вас есть что-то нетривиальное - вперед. Тут ведь кроме "помогите составить запрос" редко что попадается....
...
Рейтинг: 0 / 0
10.06.2005, 12:15
| Ответить | Цитировать | Написать  
2 Хрен
    #33111568
Фотография Berkut
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Berkut
Участник
2 Astron

Дык хотелось бы увидеть решения как тривиальных задач, так и нетривиальных, т.е. тех, которые реально применимы на практике. :)
...
Рейтинг: 0 / 0
10.06.2005, 12:22
| Ответить | Цитировать | Написать  
17 сообщений из 17, страница 1 из 1
Форумы / MySQL [игнор отключен] [закрыт для гостей] / 2 Хрен
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=47&msg=33111391&tid=1853962]:
 0ms
get settings:
 8ms
get forum list:
 15ms
check forum access:
 3ms
check topic access:
 3ms
track hit:
 182ms
get topic data:
 6ms
get forum data:
 2ms
get page messages:
 42ms
get tp. blocked users:
 1ms
others: 215ms
total:  477ms
созд. / загр.: 477ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]