|
|
|
Хранение порядка строк в таблице
|
|||
|---|---|---|---|
|
#18+
Приветствую! Приложение клиент-сервер. Все на ХП. Delph/SQL Server 2008 R2, но не суть. Подскажите "правильное" решение вот такой задачи: Пользователь вводит операции (записи) в определенном порядке - ему этот порядок важен. Нужно уметь вставлять новую операцию (читай запись) внутрь, тасовать (драг-н-дроп) операции, удалять. Как правильно организовать структуру хранения? Пока варианта 3 в башку пришло: 1. Хранить номер записи в отдельном поле. При вставке новой записи или перемещения - перенумеровывать весь набор данных. +Простота и понятность реализации. -Необходимость обновлять весь набор данных на клиенте после каждой вставки, удаления и перемещения. Частично проблему можно решить, если повторять операцию на клиенте, не обновляя весь набор. 2. Связной список. Хранить поле, ссылающееся на предыдущий элемент. +Вставка, удаление затрагивает только две записи. -Чуть более сложный select (CTE). Если в БД ковыряться напрямую (такое бывает), то можно разорвать список. Защититься можно триггером. 3. Сделать поле номера записи типа float. И при вставке находить среднее между вставляемыми записями и писать туда. +Естественный порядок сортировки сохраняется. Запрос уж через row_number(order by float_index). -Нельзя вставить очень много записей, т.к. разрешающая способность float ограничена. ну вставка 20 записей "расщепит" его до одной миллионной. Можно конечно, каждые 20 (или другое кол-во) вставок делать перенумерацию (как в старом добром бейсике). Но это все "мои велосипеды". Может есть нормальные, проверенные временем, решения, лишенные недостатков? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.10.2015, 15:07 |
|
||
|
Хранение порядка строк в таблице
|
|||
|---|---|---|---|
|
#18+
>1. Хранить номер записи в отдельном поле. Да, причем int >как в старом добром бейсике Да, только не через 10, а что нибудь со степенью двойки >каждые 20 (или другое кол-во) вставок делать перенумерацию Не каждые n, а когда вставить не получится: операция 6,7,8 - пользователь сдвинул операцию 8 в середину - пошла перенумерация только для этой сессии пользователя ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.10.2015, 16:09 |
|
||
|
Хранение порядка строк в таблице
|
|||
|---|---|---|---|
|
#18+
dymka1. Хранить номер записи в отдельном поле. проще всего. Нет даже смысла выдумывать что-то кроме этого типового решения. p.s. это кстати (№1) не "твой велосипед", а типовое решение. Вот остальные варианты конечно твои велосипеды. Сделай проще... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.10.2015, 16:18 |
|
||
|
Хранение порядка строк в таблице
|
|||
|---|---|---|---|
|
#18+
dymka, 1) или 3), в зависимости от того, как часто производится перенумерация, и как велика таблица. Есть и промежуточное решение (вполне очевидное) -- хранить порядковый номер в виде числа с фиксированной точкой (int, numeric) , но через , скажем, 10, и соотв. либо вставлять в центр, либо если нет уже места -- перенумеровывать. НО может быть идея с float не так и плоха, просто надо вставлять изначально с нормальными интервалами между записями, а то потом чисто теоретически при делении диапазонов возможа потеря значимости. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.10.2015, 16:41 |
|
||
|
Хранение порядка строк в таблице
|
|||
|---|---|---|---|
|
#18+
MasterZivможет быть идея с float не так и плоха, просто надо вставлять изначально с нормальными интервалами между записями С ней прикол в том, что количество итераций до потери точности не зависит от начальных интервалов. Double надо использовать вместо Float. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.10.2015, 16:56 |
|
||
|
Хранение порядка строк в таблице
|
|||
|---|---|---|---|
|
#18+
Вы уверены, что этот момент вообще нужно оптимизировать? У Вас будут десятки тысяч пользователей, одновременно переставляющие что-то в своих тысячных наборах? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.10.2015, 16:57 |
|
||
|
Хранение порядка строк в таблице
|
|||
|---|---|---|---|
|
#18+
Сама-то таблица может и большая, но пользователь работает со срезом не более 100 записей. Проблема не в оптимизации - там реально один срез редактирует один человек, просто интересно, как такая задача решается в РБД "академически" что-ли. Ну и как-то неправильно, на мой взгляд, после правки каждой записи заново запрашивать весь набор, пусть и всего 100 записей. Или при вставке одной записи внутрь выполнять апдейт этих 100 записей (ну ладно, в среднем меньше в два раза, так как апдейтить нужно только записи с большим номером). Отсюда и размышления мои... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.10.2015, 07:51 |
|
||
|
Хранение порядка строк в таблице
|
|||
|---|---|---|---|
|
#18+
dymkaСама-то таблица может и большая, но пользователь работает со срезом не более 100 записей. Проблема не в оптимизации - там реально один срез редактирует один человек, просто интересно, как такая задача решается в РБД "академически" что-ли. Ну и как-то неправильно, на мой взгляд, после правки каждой записи заново запрашивать весь набор, пусть и всего 100 записей. Или при вставке одной записи внутрь выполнять апдейт этих 100 записей (ну ладно, в среднем меньше в два раза, так как апдейтить нужно только записи с большим номером). Отсюда и размышления мои... Ну если разделить целое на части (диалектика типа) и смотреть только на часть БД (без клиента), то как бы Вы ставите вопрос о хранении информации о манипуляциях объектами. Ну тада как обычно в таких случаях можно начать с концепции: добавить сущность манипулирования объектами: имя типа "Операции манипулирования операции" (при первом придумывании можно самые дурацкие имена, мне кажется). Потом свой-ства: типа ИД обоекта, ИД Пред, ИД Некст, Порядок операции по времени. Типа то которое позже по времени то и актуально. Тут явно меняется толко одна сущности при одном перемещении, но вычисление нужной инфы в РМД может быть посложнее. Потом все это уже пытаться встоить в таблы логическое проектирование. Там рассмотреть и Ваши 1 и 2 варианты , и варианты с новыми таблицами для этой информации. по сложности запросов и по апдейтам. Искать оптимальное для Вашей ситуации. Так, мне кажется, и больше шансов не пропустить варианты. И как бы более укладывается в схемы методологий проектирования рекомендованные в книжках. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.10.2015, 12:12 |
|
||
|
Хранение порядка строк в таблице
|
|||
|---|---|---|---|
|
#18+
Dimitry SibiryakovMasterZivможет быть идея с float не так и плоха, просто надо вставлять изначально с нормальными интервалами между записями С ней прикол в том, что количество итераций до потери точности не зависит от начальных интервалов. Double надо использовать вместо Float. Да, вообще да. Прикольно, что интуитивно это неясно... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.10.2015, 12:36 |
|
||
|
Хранение порядка строк в таблице
|
|||
|---|---|---|---|
|
#18+
для трехзвенной архитектуры конечно немного "дикостью" выглядит обсуждение настолько уже банального вопроса, что его и вопросом назвать нельзя. Уже и сущности в ход пошли и диалектика. Это не в сторону авторов высказываний, а просто сама постановка вопроса, которая и не всплыла бы даже. Речь идет о банальной милисекундной нумерации строк и отправке серверу в итоге примитивного SQL на update ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.10.2015, 12:37 |
|
||
|
Хранение порядка строк в таблице
|
|||
|---|---|---|---|
|
#18+
dymkaСама-то таблица может и большая, но пользователь работает со срезом не более 100 записей. Проблема не в оптимизации - там реально один срез редактирует один человек, просто интересно, как такая задача решается в РБД "академически" что-ли. Это не какая-то супермега математическая задача. Нужен порядок -- храни. Нужно менять порядок -- перенумеруй. dymkaНу и как-то неправильно, на мой взгляд, после правки каждой записи заново запрашивать весь набор, пусть и всего 100 записей. Что неправильного ? 100 записей -- немного. Операция сортировки затрагивает все записи, почему бы их и не перечитать ? Миллион записей человек бы руками не стал сотрировать -- просто не сможет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.10.2015, 12:40 |
|
||
|
Хранение порядка строк в таблице
|
|||
|---|---|---|---|
|
#18+
dymka, В варианте 3 вместо Float может быть достаточно длинное символьное поле. А порядок работы - примерно как с Float. Посередине - условная точка. Слева идет нумерация записей, добавляемых в конец. Справа - вставленных в середину. Например, добавлены три записи: 000123. 000124. 000125. А теперь впихиваем между ними еще две: 000123. 000123.1 000123.2 000124. 000125. Это и охота, и зверей убивать всю таблицу перенумеровывать не надо. А вообще, конечно, бери вариант 1. На 2 и 3 смотреть, только если предвидятся реальный проблемы с массовой перенумерацией. Еще можно добавить отдельное поле - номер раздела. Тогда позиция строки = номер раздела + номер строки в разделе. При вставке строки перенумеровывать придется только один раздел. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.10.2015, 13:34 |
|
||
|
Хранение порядка строк в таблице
|
|||
|---|---|---|---|
|
#18+
dymkaНо это все "мои велосипеды". Может есть нормальные, проверенные временем, решения, лишенные недостатков? Нормального решения нет, т.к. вы пытаетесь решить задачу которая в рамках РМД решается плохо (точнее никак). Поэтому так или иначе будет сделан костыль. Какой костыль выбрать зависит от задачи. Я бы вообще посмотрел в сторону не РМД-ных расширений БД. Например массивы или JSON-типы. Но опять же это зависит от задачи и насколько нужны "отношения" в "порядках". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.10.2015, 14:03 |
|
||
|
Хранение порядка строк в таблице
|
|||
|---|---|---|---|
|
#18+
Cane Cat FisherПри вставке строки перенумеровывать придется только один раздел. Какая разница в каком поле перенумеровывать - все равно ведь это придется делать. Так что смысла в номере раздела нет никакого. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.10.2015, 17:35 |
|
||
|
Хранение порядка строк в таблице
|
|||
|---|---|---|---|
|
#18+
Народ вы что? Какое символьное поле, какой float, зачем для воробьев использовать даже не пушку, а межконтинентальную баллистическую ракету. Порядковый номер этапа должен быть уникальным только для операции. Сколько может быть этапов в операции для сортировки человеком: десятки, максимум сотни, да хоть бы и тысячи. В int32 хранится два миллиарда значений, делай шаг в миллион и перенумерация превратится в чистую теорию. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.10.2015, 18:43 |
|
||
|
Хранение порядка строк в таблице
|
|||
|---|---|---|---|
|
#18+
SERG1257В int32 хранится два миллиарда значений, делай шаг в миллион и перенумерация превратится в чистую теорию..... если не изменять порядок ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.10.2015, 19:02 |
|
||
|
Хранение порядка строк в таблице
|
|||
|---|---|---|---|
|
#18+
на самом деле много существует различных документов, где нумерация имеет важное значение. И конечно требуется функция для ее изменения, и всегда встречаются ситуации когда требуется изменить порядок, вставлять строки в середину и т.п. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.10.2015, 19:12 |
|
||
|
Хранение порядка строк в таблице
|
|||
|---|---|---|---|
|
#18+
iscrafm если не изменять порядок Не понял Первая запись - 1 Вторая запись - миллион Третья запись - два миллиона Третья запись пошла в середину между первой и второй - получила номер пол-миллиона Бывшая вторая с номером миллион пошла в середину - получила номер четверть миллиона и так далее. Пусть пользователь развлекается с этим 20 раз - следующая запись получила номер два Теперь передвинуть в середину уже нельзя - вот только тогда и перенумеруем все записи - первой номер 1 второй миллион третьей два миллиона Надо передвинуть вперед списка - назначаем номер минус миллион. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.10.2015, 19:44 |
|
||
|
Хранение порядка строк в таблице
|
|||
|---|---|---|---|
|
#18+
SergueiCane Cat FisherПри вставке строки перенумеровывать придется только один раздел. Какая разница в каком поле перенумеровывать - все равно ведь это придется делать. Так что смысла в номере раздела нет никакого. Разница в том, перенумеровывать ли все миллионы записей, или только десяток - в пределах одного раздела. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.10.2015, 20:53 |
|
||
|
Хранение порядка строк в таблице
|
|||
|---|---|---|---|
|
#18+
Если кому интересно. Сделал по чуть-чуть модифицированному варианту №1 - нумерация идет через 2: + Проще вставить новую запись (вставка нечетного номера между записями). + Проще переместить запись (драг-н-дроп) - просто присваивается новый нечетный номер между двух других записей. После этих операций - один апдейт на "renum" опять через 2. На клиенте делаю полный перезапрос, хотя потом и это можно будет избежать, осуществляя перенумерация локально параллельно с серверной. Если делать через 1, то просто тупо больше движений - часть сдвигать вверх, потом вставлять. При изменении порядка еще больше телодвижений - нужно анализировать: перемещать снизу вверх или сверху вниз итп гемор. Как справедливо заметили, это не такая супер-пупер мегазадача, просто хотелось услышать разные мнения, может что-то интересное есть, а я не знаю. SERG1257, если делать шаг миллион, то этого хватить, чтобы вставить, к примеру, перед какой-то определенной записью всего 20 новых. Но к слову, у нас это редкий случай. Хотя кто их пользователей знает... Иногда такое вытворяют. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.10.2015, 11:55 |
|
||
|
Хранение порядка строк в таблице
|
|||
|---|---|---|---|
|
#18+
dymka3. Сделать поле номера записи типа float. И при вставке находить среднее между вставляемыми записями и писать туда. +Естественный порядок сортировки сохраняется. Запрос уж через row_number(order by float_index). -Нельзя вставить очень много записей, т.к. разрешающая способность float ограничена. ну вставка 20 записей "расщепит" его до одной миллионной. Можно конечно, каждые 20 (или другое кол-во) вставок делать перенумерацию (как в старом добром бейсике). Есть еще вариант этого пункта - под позицию отводится два целых поля. И потом рассматриваются как натуральная дробь. Если же хочется совсем оптимально делать, то нужно начинать по ключевым словам Self-balancing binary search tree. Упорядоченный список - это листья такого дерева. Но встанет вопрос 'А оно точно надо?' ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.10.2015, 16:21 |
|
||
|
|
start [/forum/topic.php?fid=32&msg=39084065&tid=1540457]: |
0ms |
get settings: |
9ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
152ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
54ms |
get tp. blocked users: |
1ms |
| others: | 239ms |
| total: | 491ms |
| 0 / 0 |
Извините, этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
... ля, ля, ля ...
