ReSQL.ru
     
powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Некоторый пробел по практике.
21 сообщений из 21, страница 1 из 1
Некоторый пробел по практике.
    #37334547
gehreleth
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
gehreleth
Гость
Часто так бывает что записи из таблицы нужно выводить в определенном порядке, и порядок этот надо задавать в GUI. То есть при добавлении новой записи она попадает в конец таблицы, но пользователь должен иметь возможность передвинуть ее на произвольную позицию вверх или вниз. Что-то я ни разу не видел красивого решения данной задачи. Первое что приходит в голову - ставить какой-то триггер, который при обновлении поля row_position заделывал бы дырку нумерации в старом месте, а потом проделывал бы дырку в нумерации для нового места. Так же я видел решение основанное на числах с плавающей запятой, где если нужно поместить строку между строк A и Б, берется среднее арифметическое от row_position A и Б. Что-то оба подхода мне не нравятся и создается впечатление что у меня есть какой-то большой пробел то ли в теории, то ли в практике, и вообще я хочу странного.
...
Рейтинг: 0 / 0
03.07.2011, 20:48
| Ответить | Цитировать | Написать  
Некоторый пробел по практике.
    #37334615
АнатоЛой
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
АнатоЛой
Участник
gehreleth,
1. О какой дырке в нумерации идёт речь? Пользователю нужно кроме корректно отсортированных записей ещё и номер по порядку видеть?
2. Числа с плавающей запятой - нормальное решение, если в нём учтён вариант, когда среднее арифметическое будет равно row_position А или Б из-за точности числа.
3. Возьмёшь вместо чисел с плавающей запятой для row_position строку - будешь возиться с максимальной длиной и правилами формирования row_position.
4. Возьмёшь вместо чисел с плавающей запятой целые - всё равно уткнёшься в вариант, когда среднее арифметическое будет равно row_position А и Б.
5. Не брать какое нибудь среднее значение - значит перенумеровывать ВСЕ строки - "неприкольно"...
...
Рейтинг: 0 / 0
03.07.2011, 22:23
| Ответить | Цитировать | Написать  
Некоторый пробел по практике.
    #37334659
gehreleth
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
gehreleth
Гость
АнатоЛой,

Нашел грамотный запрос для гугла под эту проблему, выглядит так "sql priority queues". Походу кроме плавающей запятой действительно ничего нет такого что не потребовало бы обновлять всю таблицу.
...
Рейтинг: 0 / 0
03.07.2011, 23:05
| Ответить | Цитировать | Написать  
Некоторый пробел по практике.
    #37334920
qwerty112
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
qwerty112
Гость
АнатоЛой...
5. Не брать какое нибудь среднее значение - значит перенумеровывать ВСЕ строки - "неприкольно"...
1
ну не ВСЕ, а только те, что "ниже" (с большим row_position)...
и делать же, это нужно - не курсором, - 2-х запросов - хватит

при вставке - 1-ин UPDATE + 1-ин INSERT
при удвлении - 1-ин DELETE + 1-ин UPDATE
даа, в транзакцию это завернуть...
имхо - вполне вариант

2
если от "теории" к "практике", то всё это "счастье" нужно как-то представить в клиентском приложении
т.е. - будет какой-то список упорядоченный + пара кнопочек "вверх"/"вниз"
(собственно, так обычно всё и выглядит в тех же микрософтовских продуктах)

вставка - в конец списка.
нужно переместить - вперёд давить кнопки "со стрелками"

в этом случае - вообще всё просто, - выполняется только "обмен" между 2-мя соседями,
одним запросом, без всяких транзакций
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
update T
set row_position = 
  case 
    when row_position=@row_position then @row_position+/- 1 
    when row_position=@row_position+/- 1  then @row_position
  end
where row_position in (@row_position, @row_position+/- 1 )
  and exists (select  1  from T where row_position = @row_position+/- 1 )
...
Рейтинг: 0 / 0
04.07.2011, 09:23
| Ответить | Цитировать | Написать  
Некоторый пробел по практике.
    #37335199
АнатоЛой
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
АнатоЛой
Участник
qwerty112АнатоЛой...
5. Не брать какое нибудь среднее значение - значит перенумеровывать ВСЕ строки - "неприкольно"...
1
ну не ВСЕ, а только те, что "ниже" (с большим row_position)...

Согласен ударился в крайности. Но есть случаи - когда таки все . В реальности - зависит от прикладной задачи.

qwerty112и делать же, это нужно - не курсором, - 2-х запросов - хватит

при вставке - 1-ин UPDATE + 1-ин INSERT
при удвлении - 1-ин DELETE + 1-ин UPDATE
даа, в транзакцию это завернуть...
имхо - вполне вариант

При плавающей точке - один простой UPDATE/DELETE/INSERT над одной записью + достаточна редкая обработка граничных случаев (не сложнее, чем в случае без средних значений).

На небольших объёмах и однопользовательской работе - всё равно.
Большие объёмы для подобной задачи придумать сложно - пропускаем.
А вот при многопользовательской работе - вариант со средним значением более эффективен.
...
Рейтинг: 0 / 0
04.07.2011, 12:02
| Ответить | Цитировать | Написать  
Некоторый пробел по практике.
    #37335291
baracs
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
baracs
Участник
gehrelethЧасто так бывает что записи из таблицы нужно выводить в определенном порядке, и порядок этот надо задавать в GUI. У меня вопрос: причем тут, вообще, БД?
gehrelethТо есть при добавлении новой записи она попадает в конец таблицы, В общем случае, это - заблуждение.
gehrelethно пользователь должен иметь возможность передвинуть ее на произвольную позицию вверх или вниз. Что-то я ни разу не видел красивого решения данной задачи. В GUI или в таблице БД?
Если в таблице БД, то красивого решения этой задачи не может быть, ибо сама задача бредовая: на кой ляд пользователю менять физическое расположение строк таблицы?
...
Рейтинг: 0 / 0
04.07.2011, 12:30
| Ответить | Цитировать | Написать  
Некоторый пробел по практике.
    #37335314
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MasterZiv
Участник
On 03.07.2011 21:48, gehreleth wrote:

> Часто так бывает что записи из таблицы нужно выводить в определенном порядке,

select * from thetable ORDER BY order_field

и
> порядок этот надо задавать в GUI.
update thetable set order_field = ... where pk = :pk

То есть при добавлении новой записи она
> попадает в конец таблицы,


Никакого конца, как и начала, у таблиц нет. Это -- твои фантазии.
Таблица -- это set (или bag), несортированный.

> Что-то оба подхода мне не нравятся и создается впечатление что у меня есть
> какой-то большой пробел то ли в теории, то ли в практике, и вообще я хочу странного.

update thetable set order_field = ... where pk = :pk
update thetable set order_field = order_field + 1 where pk > :pk

Всё, что надо для счастья.
Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
04.07.2011, 12:42
| Ответить | Цитировать | Написать  
Некоторый пробел по практике.
    #37335409
gehreleth
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
gehreleth
Гость
baracsgehrelethЧасто так бывает что записи из таблицы нужно выводить в определенном порядке, и порядок этот надо задавать в GUI. У меня вопрос: причем тут, вообще, БД?

Потому что нужно спроектировать такую схему данных для БД
baracsgehrelethТо есть при добавлении новой записи она попадает в конец таблицы, В общем случае, это - заблуждение.

Я что, написал "в физический конец таблицы"? Нет, я написал про ту таблицу которая отображается на экране у пользователя.
baracsgehrelethно пользователь должен иметь возможность передвинуть ее на произвольную позицию вверх или вниз. Что-то я ни разу не видел красивого решения данной задачи. В GUI или в таблице БД?
Если в таблице БД, то красивого решения этой задачи не может быть, ибо сама задача бредовая: на кой ляд пользователю менять физическое расположение строк таблицы?

Ну менять логическое расположение строк ляд есть, и вполне конкретный. Потому что программа генерирует отчеты, данные в которых должны отображаться в последовательности определяемой пользователем, например.
...
Рейтинг: 0 / 0
04.07.2011, 13:45
| Ответить | Цитировать | Написать  
Некоторый пробел по практике.
    #37335536
baracs
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
baracs
Участник
gehrelethbaracsпропущено...
У меня вопрос: причем тут, вообще, БД?

Потому что нужно спроектировать такую схему данных для БД Какую "такую"?

Какое отношение сортировка данных в гриде (таблице на экране) вашего GUI имеет к схеме БД?

gehrelethНу менять логическое расположение строк ляд есть, и вполне конкретный. Потому что программа генерирует отчеты, данные в которых должны отображаться в последовательности определяемой пользователем, например. Ну вот, пусть и определяет ее в приложении, генерирующем отчеты, сколько душе угодно.
...
Рейтинг: 0 / 0
04.07.2011, 15:05
| Ответить | Цитировать | Написать  
Некоторый пробел по практике.
    #37335607
АнатоЛой
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
АнатоЛой
Участник
MasterZiv
update thetable set order_field = ... where pk = :pk
update thetable set order_field = order_field + 1 where pk > :pk

Всё, что надо для счастья.


второй update - для геморроя :). По задаче подразумевается, что order_field и pk не имеют зависимости.
А этот апдейт пытается сказать, что зависимость есть. Нехорошо.
Наверное так:


update thetable set order_field = order_field + 1 where order_field >= :order_field_for_new_record;
update thetable set order_field = :order_field_for_new_record where pk = :pk;

?
П.С.: Мы не апдейты обсуждаем - а подход.
...
Рейтинг: 0 / 0
04.07.2011, 15:33
| Ответить | Цитировать | Написать  
Некоторый пробел по практике.
    #37335786
qwerty112
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
qwerty112
Гость
baracsКакое отношение сортировка данных в гриде (таблице на экране) вашего GUI имеет к схеме БД?

пример с отчётом от ТС, действительно выглядит натянуто и мало имеет отношения к схеме БД...

со схемой :)

есть сущ.Объект
идОбъектнаименование1Объект1

есть сущ.Операция
идОперациянаименование1Операция12Операция23Операция3

и есть ОперацииНадОбъектом
ПорядокВыполнения идОбъектидОперация113212313411
1
над одним объектом может выполнятся множество операций, в том числе, одна и та же операция может применятся несколько раз
2
порядок применения операций над объектом - определяет результат
(т.е. теже самые операции, выполненные над одним и тем же объектом, НО в разной последовательности - дадут разный результат )

нуу и как бы, вопрос
как дать пользователю/клиентскому приложению, простой и надёжный механизм редактирования таб.ОперацииНадОбъектом ?

т.е. возможные правки:
- удаление Операции из списка(в произвольном месте, разумеется)
- вставка новой Операции (в произвольное место списка)
- перестановка местами 2-х Операций
...и т.д.

об этом, имхо, и был вопрос ...
...
Рейтинг: 0 / 0
04.07.2011, 17:09
| Ответить | Цитировать | Написать  
Некоторый пробел по практике.
    #37335866
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MasterZiv
Участник
On 04.07.2011 16:33, АнатоЛой wrote:

> второй update - для геморроя :). По задаче подразумевается, что order_field и pk
> не имеют зависимости.
> А этот апдейт пытается сказать, что зависимость есть. Нехорошо.
> Наверное так:

Я там неправильно порядок указал, второй UPDATE должен быть первым, а первый --
всторым. И если рассуждать о геморое -- оно тут для гемороя всё.
И на счёт WHERE update-ов -- я их естественно для иллюстрации только написал,
я не знаю, какие у автора топика условия.
Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
04.07.2011, 17:35
| Ответить | Цитировать | Написать  
Некоторый пробел по практике.
    #37335894
baracs
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
baracs
Участник
qwerty112со схемой :)

есть сущ.Объект
идОбъектнаименование1Объект1

есть сущ.Операция
идОперациянаименование1Операция12Операция23Операция3

и есть ОперацииНадОбъектом
ПорядокВыполнения идОбъектидОперация113212313411
1
над одним объектом может выполнятся множество операций, в том числе, одна и та же операция может применятся несколько раз
2
порядок применения операций над объектом - определяет результат
(т.е. теже самые операции, выполненные над одним и тем же объектом, НО в разной последовательности - дадут разный результат )

нуу и как бы, вопрос
как дать пользователю/клиентскому приложению, простой и надёжный механизм редактирования таб.ОперацииНадОбъектом ?

т.е. возможные правки:
- удаление Операции из списка(в произвольном месте, разумеется)
- вставка новой Операции (в произвольное место списка)
- перестановка местами 2-х Операций
...и т.д.

об этом, имхо, и был вопрос ... Ну, если вопрос в том, как хранить в БД связь многие-ко-многим, то вы на него уже ответили: таблицу-связку сделать.

У меня же, возникло ощущение, что ТС смутно различает функционал клиентского приложения и СУБД. Отсюда и вопросы.
...
Рейтинг: 0 / 0
04.07.2011, 17:50
| Ответить | Цитировать | Написать  
Некоторый пробел по практике.
    #37336005
qwerty112
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
qwerty112
Гость
baracs Ну, если вопрос в том, как хранить в БД связь многие-ко-многим, то вы на него уже ответили: таблицу-связку сделать.

У меня же, возникло ощущение, что ТС смутно различает функционал клиентского приложения и СУБД. Отсюда и вопросы.
нуу, если "расписание" - это многие-ко-многим, то даа - тут многие-ко-многим :)

а вопрос, я вообщем-то выделил,
хотя - согласен, - вопрос несколько не для форума "Проектирование БД"
...
Рейтинг: 0 / 0
04.07.2011, 18:58
| Ответить | Цитировать | Написать  
Некоторый пробел по практике.
    #37336371
АнатоЛой
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
АнатоЛой
Участник
baracsУ меня же, возникло ощущение, что ТС смутно различает функционал клиентского приложения и СУБД. Отсюда и вопросы.

Я в шоке... То есть на клиенте себе сортируй сколько хочешь. А если завтра придёшь - то сортируй заново? Логично, что пользовательский порядок отображения данных из БД нужно сохранить в той же БД - чтобы завтра и послезавтра второй и третий раз не сортировать... В чём вопрос?...
Привожу пример - товары на полке нужно расположить сегодня в определённом порядке... И порядок задаёт сам мерчандайзер... А завтра захотелось парочку товаров переставить - и так они будут стоять недельку, пока опять не переставим... Это всё на клиенте хранить?
...
Рейтинг: 0 / 0
05.07.2011, 00:54
| Ответить | Цитировать | Написать  
Некоторый пробел по практике.
    #37336775
baracs
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
baracs
Участник
АнатоЛойbaracsУ меня же, возникло ощущение, что ТС смутно различает функционал клиентского приложения и СУБД. Отсюда и вопросы.

Я в шоке... То есть на клиенте себе сортируй сколько хочешь. А если завтра придёшь - то сортируй заново? Логично, что пользовательский порядок отображения данных из БД нужно сохранить в той же БД - чтобы завтра и послезавтра второй и третий раз не сортировать... В чём вопрос?...
Привожу пример - товары на полке нужно расположить сегодня в определённом порядке... И порядок задаёт сам мерчандайзер... А завтра захотелось парочку товаров переставить - и так они будут стоять недельку, пока опять не переставим... Это всё на клиенте хранить? Спасибо, что объяснили, чего хотел автор топика.

А то, он начал писать про последовательность данных в отчетах...

P.S. С товарами на полках пример не вполне удачный:
в таких задачах полки делятся на конечные интервалы, которые может занимать тот или иной товар. Соответственно, полки и интервалы нумеруются раз и на всегда, а меняется привязка товаров к ним.
Или просто указывается количество интервалов (юнитов), которые может (должен) занимать данный товар на полках.
...
Рейтинг: 0 / 0
05.07.2011, 10:57
| Ответить | Цитировать | Написать  
Некоторый пробел по практике.
    #37338668
gehreleth
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
gehreleth
Гость
baracsС товарами на полках пример не вполне удачный:
в таких задачах полки делятся на конечные интервалы, которые может занимать тот или иной товар. Соответственно, полки и интервалы нумеруются раз и на всегда, а меняется привязка товаров к ним.


Если речь о том чтобы печатать путевые листы для расклейщиков афиш, то есть такоое требование что данные должны быть отсортированы в том порядке в котором их обходит расклейщик, а во вторых они меняются со временем т.к в них добавляются новые щиты на новых адресах и изымаются старые. Кроме того, там есть такой функционал что нужно создать новый маршрут и перекинуть часть щитов на него.
...
Рейтинг: 0 / 0
06.07.2011, 10:57
| Ответить | Цитировать | Написать  
Некоторый пробел по практике.
    #37338925
baracs
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
baracs
Участник
gehrelethЕсли речь о том чтобы печатать путевые листы для расклейщиков афиш, то есть такоое требование что данные должны быть отсортированы в том порядке в котором их обходит расклейщик, а во вторых они меняются со временем т.к в них добавляются новые щиты на новых адресах и изымаются старые. Кроме того, там есть такой функционал что нужно создать новый маршрут и перекинуть часть щитов на него. Структура описна здесь .

Считываете в датасет своего GUI строки, относящиеся к данному маршруту.
Пользователь сортирует их в гриде.
Когда пользователь нажимает кнопку "сохранить", обновляете в датасете значения колонки [порядок выполнения], в соответствии с новым порядком сортировки, сохраняете изменения в БД.

Полагаю, за рабочий день расклейшик не сможет обойти такое количество рекламных щитов, чтобы напрячь сервер апдейтом соответствующего количества строк
...
Рейтинг: 0 / 0
06.07.2011, 12:22
| Ответить | Цитировать | Написать  
Некоторый пробел по практике.
    #37355060
Шогал
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Шогал
Участник
А если пользователей будет несколько, и каждый будет считать правильным свой порядок?
Тогда придется отдельную таблицу заводить со столбцами ид_пользователя, ид_строки, порядок.
Минусы - при выборке придется LEFT JOIN'ить отдельную таблицу и сортировать по ней.
...
Рейтинг: 0 / 0
17.07.2011, 17:08
| Ответить | Цитировать | Написать  
Некоторый пробел по практике.
    #37355148
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
gehrelethи создается впечатление что у меня есть какой-то большой пробел то ли в теории, то ли в практике, и вообще я хочу странного.
В общем да, хочешь странного. Задача сомнительная, хотя легко решаемая:

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
update MyTable set
  order# = case 
      when order# = :old_order then :new_order
      when :old_order > :new_order and 
            order# >= :new_order and
            order# < :old_order then order# +  1 
      when :old_order < :new_order and
            order# > :old_order and
            order# <= :new_order then order# -  1 
      else null -- cюда приходить не должно, пусть даст ошибку на not null поле
    end 
where 
  id = :id and order# between least(:old_order, :new_order) and greatest(:old_order, :new_order);

Может, ошибся в какой мелочи, но идея имхо понятна.
...
Рейтинг: 0 / 0
17.07.2011, 20:59
| Ответить | Цитировать | Написать  
Некоторый пробел по практике.
    #37357049
Фотография Vladimir2009
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Vladimir2009
Участник
gehrelethЧасто так бывает что записи из таблицы нужно выводить в определенном порядке, и порядок этот надо задавать в GUI. То есть при добавлении новой записи она попадает в конец таблицы, но пользователь должен иметь возможность передвинуть ее на произвольную позицию вверх или вниз. Что-то я ни разу не видел красивого решения данной задачи. Первое что приходит в голову - ставить какой-то триггер, который при обновлении поля row_position заделывал бы дырку нумерации в старом месте, а потом проделывал бы дырку в нумерации для нового места. Так же я видел решение основанное на числах с плавающей запятой, где если нужно поместить строку между строк A и Б, берется среднее арифметическое от row_position A и Б. Что-то оба подхода мне не нравятся и создается впечатление что у меня есть какой-то большой пробел то ли в теории, то ли в практике, и вообще я хочу странного.

смотря какие данные,
1) сортируй в гриде,
2) во вьюхе
3) в крайнем случае в самой таблице придусмотреть поле ORD (и снова гоу п1. или п.2)
...
Рейтинг: 0 / 0
19.07.2011, 09:40
| Ответить | Цитировать | Написать  
21 сообщений из 21, страница 1 из 1
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Некоторый пробел по практике.
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=32&msg=37334547&tid=1542084]:
 0ms
get settings:
 7ms
get forum list:
 9ms
check forum access:
 2ms
check topic access:
 2ms
track hit:
 254ms
get topic data:
 8ms
get forum data:
 2ms
get page messages:
 39ms
get tp. blocked users:
 1ms
others: 210ms
total:  534ms
созд. / загр.: 534ms
x
x
Закрыть


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