|
Помогите с запросом
|
|||
---|---|---|---|
#18+
Есть таблица с полем State, нужно выбрать уникальные из подряд идущих значений этого поля. Например, есть записи (значение поля State): 1 1 2 3 3 3 4 4 1 5 5 2 2 => нужно выбрать записи с по значением поля: 1 2 3 4 1 5 2 Смысл задачи: выбирать только переходы состояний. Выбирать нужно только первое (не любое, и не последнее) из подряд идущих дублей, остальные пропускать. Помогите написать максимально простой (стандартный) запрос, по идее задача достаточно распространенная. ... |
|||
:
Нравится:
Не нравится:
|
|||
16.12.2009, 20:16 |
|
Помогите с запросом
|
|||
---|---|---|---|
#18+
первичный ключ определен? ... |
|||
:
Нравится:
Не нравится:
|
|||
17.12.2009, 18:55 |
|
Помогите с запросом
|
|||
---|---|---|---|
#18+
Задачка на потоковую обработку, т.е. уровня приложения. Как вариант: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22.
Все равно вам нужно извлечь _все_ данные, индекс тут не поможет. Фактически, вы пытаетесь алгоритм сжатия реализовать на SQL - если добавить еще кол-во элементов в каждой из последовательных серий, получится простейший архиватор :-) ... |
|||
:
Нравится:
Не нравится:
|
|||
17.12.2009, 21:32 |
|
Помогите с запросом
|
|||
---|---|---|---|
#18+
White Owlпервичный ключ определен? да, id. порядок следования по нему (order by id) - т.е. по мере добавления состояний. был бы pl/sql можно было бы заюзать lag/lead, на C# делается еще проще - простой последовательной обработкой: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14.
но тут SQL. неужели это такой редкий запрос? ... |
|||
:
Нравится:
Не нравится:
|
|||
18.12.2009, 20:54 |
|
Помогите с запросом
|
|||
---|---|---|---|
#18+
Все равно вам нужно извлечь _все_ данные, индекс тут не поможет. Фактически, вы пытаетесь алгоритм сжатия реализовать на SQL - если добавить еще кол-во элементов в каждой из последовательных серий, получится простейший архиватор :-) так то оно так, с двумя _НО_:одно дело БД пролопатит таблицу на такие соответствия - по идее шустрее тк не будет извлекать _все_ поля, + не будет гонять данные между слоем БД и business-tier ... |
|||
:
Нравится:
Не нравится:
|
|||
18.12.2009, 20:59 |
|
Помогите с запросом
|
|||
---|---|---|---|
#18+
super_bВсе равно вам нужно извлечь _все_ данные, индекс тут не поможет. Фактически, вы пытаетесь алгоритм сжатия реализовать на SQL - если добавить еще кол-во элементов в каждой из последовательных серий, получится простейший архиватор :-) так то оно так, с двумя _НО_:одно дело БД пролопатит таблицу на такие соответствия - по идее шустрее тк не будет извлекать _все_ поля, + не будет гонять данные между слоем БД и business-tier Простите, где "гонять" данные?! SQLite - встраиваемая СУБД, исполняется в адресном пространстве приложения, так что "гонять" ничего не нужно. Что касается извлечения _всех_ полей - это неизбежно в любом случае для СУБД с построчным хранением данных, каковых подавляющее большинство (эскулайт, постгрес, мускуль, оракл и проч.). ... |
|||
:
Нравится:
Не нравится:
|
|||
18.12.2009, 22:10 |
|
Помогите с запросом
|
|||
---|---|---|---|
#18+
super_bWhite Owlпервичный ключ определен? да, id. порядок следования по нему (order by id) - т.е. по мере добавления состояний. В следующий раз сразу публикуй скрипт создающий тестовую таблицу. Я сегодня добрый, поэтому написал ее за тебя. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25.
... |
|||
:
Нравится:
Не нравится:
|
|||
19.12.2009, 00:57 |
|
Помогите с запросом
|
|||
---|---|---|---|
#18+
White Owl... Страшный запрос, даже если создать индекс. Вообще это частный случай более общей проблемы, я уже написал функцию, которая это решает, да еще предоставляет эмуляцию конструкции "distinct on": Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8.
Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34.
Вместо использования хэша можно хранить бинарную строку со всеми значениями, но я полагаю, что вероятность коллизии 1 к 4 миллиардам не так существенна, а при использовании нескольких аргументов distincton(0,value1,value2,...,valueN) имеет смысл именно хэш. У меня в продакшене есть несколько запросов, которые требуют подобной оптимизации, т.к. сейчас с помощью триггеров обновляются флаги is_first/is_last у записей, а мне это категорически не нравится. Функция скоро будет опубликована в моем репозитории, см. http://sqlite.mobigroup.ru/ ... |
|||
:
Нравится:
Не нравится:
|
|||
19.12.2009, 01:38 |
|
Помогите с запросом
|
|||
---|---|---|---|
#18+
MBGWhite Owl...Страшный запрос, даже если создать индекс.С этим никто не спорит :) Чисто как игра ума, решить задачу не выходя за пределы SQL возможно. Получится конечно кошмар с точки зрения производительности, но решить ее возможно. Намного правильней будет либо добавить в таблицу флаг "переключаем на новое значение". либо считать на клиенте. А твой любимый подход с написанием расширения для sqlite... Я соглашусь что это самое производительное и самое нетребовательное к ресурсам решение, но в тоже время это и самое сложное для сопровождения и расширения. Но производительное.... но сложное в сопровождении.... но производительное... но сложное.... ... |
|||
:
Нравится:
Не нравится:
|
|||
19.12.2009, 19:53 |
|
Помогите с запросом
|
|||
---|---|---|---|
#18+
White OwlMBGWhite Owl...Страшный запрос, даже если создать индекс.С этим никто не спорит :) Чисто как игра ума, решить задачу не выходя за пределы SQL возможно. Получится конечно кошмар с точки зрения производительности, но решить ее возможно. Намного правильней будет либо добавить в таблицу флаг "переключаем на новое значение". либо считать на клиенте. Зачастую бывает лучше два десятка строк для дополнительной функции написать, чем поддерживать в проекте сотни строк кода разработчиков, реализующих эту функциональность триггерами в БД и/или функциями на уровне приложения. White Owl А твой любимый подход с написанием расширения для sqlite... Я соглашусь что это самое производительное и самое нетребовательное к ресурсам решение, но в тоже время это и самое сложное для сопровождения и расширения. Но производительное.... но сложное в сопровождении.... но производительное... но сложное.... Апстрим эскулайта в таких случаях отвечает, что если вам нужно решить вашу задачу - решайте ее, пишите свой код, не стесняйтесь модифицировать исходник, ведь эскулайт - встраиваемая СУБД, так что каждый проект, по идее, пользуется своей собственной сборкой. SQLite API настолько стабилен, что сопровождение сложности не представляет - достаточно раз в месяц сливать свою версию с очередным релизом апстрима. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.12.2009, 03:03 |
|
Помогите с запросом
|
|||
---|---|---|---|
#18+
Переписал для работы без дополнительного модуля murmurhash и сделал поддержку произвольного кол-ва аргументов: http://sqlite.mobigroup.ru/src/info/c702c868dc Для работы функции нужен однострочный патч http://sqlite.mobigroup.ru/src/info/325d887bb1 С этим патчем связаны интересные размышления, пока скажу лишь, что Anton Kovalenko решил написать дополнительный интерфейс, а не патчить существующий. Его патч я в альтернативную ветку включу, а потом посмотрим, удастся ли одному из нас убедить апстрим. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.12.2009, 20:50 |
|
|
start [/forum/topic.php?fid=54&msg=36376081&tid=2009395]: |
0ms |
get settings: |
9ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
80ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
47ms |
get tp. blocked users: |
2ms |
others: | 13ms |
total: | 183ms |
0 / 0 |