SQLite - Как пересчитать id в столбце?

[SpetZ_Naz]

Здравствуйте, уважаемые форумчане!

Есть необходимость пересчитать Праймари кей Id после удаления записи в базе данных Сиквел. Например, есть пять записей с Id = 1, 2, 3, 4, 5. Удаляю третью запись: 1, 2, 4, 5. Необходимо вернуть Id прежнюю последовательность - по возрастанию без прерываний.
Читал подобный вопрос на другом форуме, но немного не разобрался. Может кто уже реализовывал подобное?

[Zebestov]

Трогать ID после записи — плохая затея. Это же не какое-то там поле для удовлетворения перфекционистов, это уникальный идентификатор записи!

[bifidokk]

Расскажите лучше, зачем вам это надо.
В посте как раз написано, что следует завести доп. поле, которое будет указывать на порядковый номер, а не использовать столец, на котором висит primary индекс.

По сути вы при каждой вставке считаете количество записей в таблице, при это позиция новой записи будет равна N + 1, где N - текущее кол-во записей.

Далее при удалении вы берете все записи, которые "выше" удаляемой и декриментите у них позицию.

[SpetZ_Naz]

Сообщение от Zebestov

...это уникальный идентификатор записи!

Согласен. По нему я нахожу редактируемую строчку в таблице и через него могут быть связи с другими таблицами базы.

Ход моих мыслей: этот столбец я использую в качестве порядкового номера записи в DataGrid. Столбец у меня называется "№ з\п" которому я присваиваю этот Primary key. Клацая по ячейке пользователь, так скажем, привязывается к записи через порядковый номер и все запросы обращаются через "№ з\п". Соответственно удаляя строчку, удаляется и красивый порядок возрастания "№ з\п", хоть и суть обращения к записям не меняется. Изложил очевидные вещи, но в этом суть.

Идея с дополнительным столбцом в общем то понятна, но сразу возникает вопрос: если записей будет тысяча и удалю я третью строчку, то нужно сделать 997 запросов в базу дабы декрементировать все порядковые номера что выше... В посте я не разобрался как это сделать. Может есть реализации, ссылки на удачные примеры? Ну или может кто подскажет другую логику вывода базы данных в приложение и обращение к ее строкам..

[Zebestov]

1. ID на протяжении жизни базы менять не следует.
2. Вся эта визуальная красота с порядковыми номерами делается с помощью LIMIT & OFFSET

[bifidokk]

Ход моих мыслей: этот столбец я использую в качестве порядкового номера записи в DataGrid. Столбец у меня называется "№ з\п" которому я присваиваю этот Primary key. Клацая по ячейке пользователь, так скажем, привязывается к записи через порядковый номер и все запросы обращаются через "№ з\п". Соответственно удаляя строчку, удаляется и красивый порядок возрастания "№ з\п", хоть и суть обращения к записям не меняется. Изложил очевидные вещи, но в этом суть.

2. Вся эта визуальная красота с порядковыми номерами делается с помощью LIMIT & OFFSET

И не усложняйте себе жизнь. Заводите счетчик, который будет порядковым номером. При выводе каждой строчки инкрементите его и так же выводите. Если у вас выводятся записи с 20 по 30, то и счетчик изначально будет не 0, а 20.

Клацая по ячейке пользователь, так скажем, привязывается к записи через порядковый номер и все запросы обращаются через "№ з\п".

А это неправильно. Обращайтесь через primary key

[SpetZ_Naz]

Спасибо за ответы.

Сообщение от Zebestov

1. ID на протяжении жизни базы менять не следует.

Понятно, таки нужно заводить дополнительный столбец с порядковым номером.

2. Вся эта визуальная красота с порядковыми номерами делается с помощью LIMIT & OFFSET

Материал хороший, спасибо, но мне бы пример реализации по возможности или ссылки на практику, быстрее разберусь.

Сообщение от bifidokk

И не усложняйте себе жизнь. Заводите счетчик, который будет порядковым номером. При выводе каждой строчки инкрементите его и так же выводите. Если у вас выводятся записи с 20 по 30, то и счетчик изначально будет не 0, а 20.

На реальном коде проще разобраться. Тоже прошу по возможности реализацию кидануть или ссылку, так как первая цитата Zebestov'а перечет Вашей (по крайней мере я так понял). Дабы не запутаться нужно переходить на примеры.


.

[Zebestov]

Нет нет, ничего не перечит.
Ты создаешь записи, ID инкрементится.
Удаляешь записи, ряд ID перестает быть непрерывным, приобретает пропуски.
Таким образом у тебя всю жизнь базы ID конкретной записи всегда один и тот же.
При отображении ты будешь использовать LIMIT и OFFSET для постраничного вывода строк из базы (1...10, 11...20 и т.д.). Так вот эти номера строк не имеют ни какого отношения к ID базы, они просто для красоты, чтобы пользователь радовался. Но если он выберет конкретные записи и захочет с ними что-то сделать, твое отображение всегда будет знать, что, например:

1-я запись — это ID = 1
2-я запись — это ID = 2
3-я запись — это ID = 4, бо вчера запись с ID = 3 потерли
…
10-я запись — это ID = 11 (бо до этого момента только третью запись удалили)

Вот и вся любов.

[SpetZ_Naz]

Сообщение от Zebestov

Вот и вся любов.

Да, очень даже доходчиво объяснили, спасибо. Теперь мне наверное нужно объяснить логику приложения, так как видимо LIMIT и OFFSET мне не очень подходят (сори, что сразу не уточнил эти детали). Дело в том, что при запуске приложения я делаю 5-6 запросов и получаю столько же массивов с результатами SQL запроса и формирую столбцы и строки в DataGrid. Тоесть я частично отхожу от классических запросов в базу и работаю со стандартными возможностями массивов: Array.filter(). Есть несколько фильтров на основе компонента List, по которым в доли секунды производится поиск данных. Дальше пользователь произвел изменения в DataGrid и зная что поле "№з/п" у меня выполняет функцию уникального Id записи в базе, я могу вносить изменения в базу.

Может я как-то неправильно это реализовал? Через чур упростил себе жизнь и дальше мне это выльется в последствиях? И как в моем случае реализовать красивый порядковый номер столбца "№з/п", только дополнительным столбиком в базе?

[Zebestov]

Ну можно при выборке просто на лету собрать все данные в объект, в котором среди прочих данных из базы, включая ID, будет поле, скажем, num, которое и указывает порядковый номер в твоем списке. Таким образом твое приложение в любой момент будет знать, какой ID у записи номер 100500.

Разумеется при удалении некоторых записей в течение сессии тебе конечно же придется делать пересчет (декремент) всех "num" после удаленной. Но это лишь на протяжении сессии(!) и лишь в данном конкретном приложении, а не в базе, чтобы конкретный пользователь работал со своими красивыми порядковыми номерами, не внося путаницу в БД.

Однако это тоже можно счесть путаницей — как бы пользователь не забыл, что он только что удалил запись №100500 и теперь под этим номером уже совсем другие данные (а именно те, которые стояли следом).

В обычных клиентах такое не происходит, потому что порядковые номера — это всего лишь декор. Ну т.е. следователь не парится, что папка с делом №3 теперь на самом верху, потому что два предшествующих дела уже закрыли. Он всегда работает не с порядком расположения папок в стопке, а с их номерами.

Либо я не знаю какой-то особенной роли именно порядка вывода данных в нумерованный список, либо ты слишком уж много внимания уделяешь этой нумерации.