Как сделать что бы id строки в таблицы начиналось с 1 даже после удаления нескольких строк?

Question

[Prit1]

У меня возникла проблема, что при удалении строк из таблицы нарушается порядок id, как это решить, чтобы при любом удалении строки порядок id не нарушался и всегда начинался с 1

Answer 1

[Ivan Yakushenko]

Не нужно удалять записи, просто заменяйте строку на null, тогда и проблем не будет в вашем случае.

Comments

[Пасечник Кузьмич]

Костыль.

Answer 2

[Сергей Горностаев]

Не надо так делать. Вся суть идентификаторов в их неизменности.

Comments

[Prit1]

Просто моя проблема состоит в том, что мне нужно чтобы все строки имели всегда id типа : 1, 2, ,3 ,4 ,5. А при удалении к примеру первой строки получается что отчёт идёт не с 1, а 2, типо: 2, 3, 4, 5; а не 1, 2, 3, 4 как хотелось

[Сергей Горностаев]

Prit1, зачем?

[Prit1]

потому что я пишу сервер, который будет общаться с android приложением, на котором будет тоже будет своя база данных, а там id такого типа, и получается когда я буду обращаться к серверу я буду запрашивать по id типа 1, 2, 3, 4. И если они будут отличаться, я не смогу запросить нужные мне данные (если я не прав поправьте, я новичок в этом)

[Сергей Горностаев]

Prit1, вы не правы.

[Prit1]

Сергей Горностаев, можно тогда пояснить в чём, чтобы я имел представление)?

[Ivan Yakushenko]

Prit1, например: зачем приложению своя база, если вы и так подключаетесь к сторонней, в которой хранятся, как я понял, такие-же самые данные?

[Prit1]

Ivan Yakushenko, ну да, смысл в том, что база которая на телефоне будет копировать данные с сервера, и если не будет связи с сервером (к примеру не будет интернета) то будет грузиться база которая на телефоне

[Ivan Yakushenko]

Prit1, зачем вы вообще используете id в качестве идентификатора пользователя, более того, что происходит в вашем приложении, что может быть удалена целая строка? Оставляйте просто null, тогда не будет проблем. Изменять данные проще, чем удалять и проблем всегда меньше.

[Prit1]

Ivan Yakushenko, удалять строки мне нужно потому что если кратко объяснить смысл приложения, то есть пользователь который, создаёт проект (каждый проект строка в базе данных) и он может их редактировать и удалять по надобности

[Ivan Yakushenko]

Prit1, я еще раз повторяю: зачем вы в самой базе то удаляете строку? Скиньте значения в null и не будет проблем. Или вам несколько бит памяти жалко?

[Prit1]

Ivan Yakushenko, хотя у меня появилась благодаря вам идея. Чтобы не засерать базу, когда пользователь типо удаляет строку, она просто становится пустой и если ему нужно создать ещё одну, то не создаёт а заполняет пустую. Спасибо за совет, попробую реализовать

[Prit1]

Ivan Yakushenko, напишите как ответ и я вам засчитаю за решение

[Сергей Горностаев]

Prit1, во-первых, при синхронизации двух баз неизменность идентификаторов ещё важнее. Например, в БД на сервере есть таблица, в которой хранится пользовательский баланс

id |   name   | ammount
---+----------+------------
1  | Иванов   | 500
---+----------+------------
2  | Петров   | 10
---+----------+------------
3  | Сидоров  | 3000

При первой синхронизации мобильного приложения с серверов, вы сделали копию этой базы. Потом мобильное устройство потеряло связь, и в этот момент на сервере удалили запись Петрова и пересчитали идентификаторы по порядку. При следующей синхронизации вам придётся или полностью перезалить базу мобильного базой серверной, потеряв все внесённые изменения, или у вас возникнет конфликт - в мобильном приложении у пользователя с идентификатором 2 на балансе 10, а на сервере 3000.

Выхода из этой ситуации два:
1. Естественные ключи - если фамилии уникальны, то идентифицировать записи можно по ним, просто убрав поле id.
2. Серверные идентификаторы - в таблицу БД мобильного приложения добавляется ещё одно поле server_id, которое может быть null, и в него при синхронизации записываются id из БД сервера. Если в поле null, значит запись создана на клиенте и ещё не отправлялась на сервер. Если в поле значение, но на сервере его нет, значит на сервере оно было удалено и надо удалить из локальной БД. Если запись с таким id есть и на сервере и на клиенте, то идентификатор можно использовать для синхронизации данных только изменённых строк, экономя трафик и исключая ошибки целостности.

Во-вторых, пересчёт идентификаторов - это ооочень медленная процедура. Вам нужно заблокировать всю таблицу целиком на всё время пересчёта, выбрать все записи, последовательно изменить им идентификаторы и записать обратно. И пока это происходит, никто не сможет обратиться к этой таблице. А теперь представьте, что будет если в таблице миллион строк.
В-третьих, идентификаторы служат внешним ключом, для связи между таблицами и для построения индексов. То есть, чтобы сохранить целостность и непротиворечивость данных придётся заблокировать и изменить заодно и связанные таблицы, а также перестроить индексы. Ваш сервер на этой бессмысленной задаче сожрёт огромное количество ресурсов.

Answer 3

[Дмитрий Шицков]

порядок id не нарушался

Порядок id при автоинкременте не нарушается. Всегда идёт по возрастанию.

Если вы хотите перенумеровывать строки, потребуется затрачивать немало ресурсов для того, чтобы поменять номера всех записей в случае удаления любой строки. Да и какой в этом смысл?