Сообщение Re[2]: изменения порядка в списке от 16.11.2022 19:02
Изменено 16.11.2022 19:03 ·
Re[2]: изменения порядка в списке
Здравствуйте, paucity, Вы писали:
P>Добавить в запись два поля prev_id, next_id; где _id — что-то уникально идентифицирующее каждую запись.
P>ЗЫ. можно и одно поле, но два удобнее, имхо
Не, можно и одно, т.к. можно искать записи по критерию where prev_id=?.
Другое дело, я тут подумал, что такой способ не позволяет сделать простой order by, приходится рекурсивный CTE ваять, что может плохо отразиться на производительности как минимум...
P>Добавить в запись два поля prev_id, next_id; где _id — что-то уникально идентифицирующее каждую запись.
P>ЗЫ. можно и одно поле, но два удобнее, имхо
Не, можно и одно, т.к. можно искать записи по критерию where prev_id=?.
Другое дело, я тут подумал, что такой способ не позволяет сделать простой order by, приходится рекурсивный CTE ваять, что может плохо отразиться на производительности как минимум...
Re[2]: изменения порядка в списке
Здравствуйте, paucity, Вы писали:
P>Добавить в запись два поля prev_id, next_id; где _id — что-то уникально идентифицирующее каждую запись.
P>ЗЫ. можно и одно поле, но два удобнее, имхо
Не, можно и одно, т.к. можно искать записи по критерию where prev_id=?.
Другое дело, я тут подумал, что такой способ не позволяет сделать простой order by, приходится рекурсивный CTE ваять, что может плохо отразиться на производительности как минимум... Ну или сортировать на клиенте.
В общем, такое ощущение, что шило на мыло меняется.
P>Добавить в запись два поля prev_id, next_id; где _id — что-то уникально идентифицирующее каждую запись.
P>ЗЫ. можно и одно поле, но два удобнее, имхо
Не, можно и одно, т.к. можно искать записи по критерию where prev_id=?.
Другое дело, я тут подумал, что такой способ не позволяет сделать простой order by, приходится рекурсивный CTE ваять, что может плохо отразиться на производительности как минимум... Ну или сортировать на клиенте.
В общем, такое ощущение, что шило на мыло меняется.