LINUX.ORG.RU

MySQL - вставка строчки между двумя существующими

 , , ,


0

1

Задача такая: есть блоки текста в таблице `id | text | created_at | ...`, которые могут быть разбиты на меньшие. Естественно, фрагменты не должны оказаться в конце с наибольшим id (primary_key, autoincrement), потому что по id упорядочивается вывод текста.

update sentences set id=id+1 where id>=6 order by id desc;
insert into sentences (id, name) values (6, 'trash')

Вообще, я думаю, что трогать autoincrement некрасиво, вдобавок я использую django orm, а это значит, что при наличии FK на запись, все ссылки при сдвиге сломаются.

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

Поэтому мне любопытно, как сделать это нормально.

Нормально - еще по одному полю

pi11 ★★★★★
()

Сломал мозг пытаясь найти тут вопрос или задачу. Или хотя бы вообще какой-то смысл.

ei-grad ★★★★★
()

а это значит, что при наличии FK на запись, все ссылки при сдвиге сломаются.

FK для того и используют (в том числе), чтобы можно было ID менять. Если способ связи стоит CASCADE, то обновится всё, что ссылается на изменяемый ID. Но изменять ID — всё равно моветон, да.

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

KRoN73 ★★★★★
()
Ответ на: комментарий от KRoN73

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

истинно так.

а еще в примере автора если не использовать блокировки, то можно поиметь нехилый баттхерд, если одновременно 2 таких скрипта пустить

Gordon01 ★★
()

Это домашнее задание или где-то в реальной системе такое будет?

vromanov ★★★
()

Знатный треш и угар.

Поэтому мне любопытно, как сделать это нормально.

Нормально - это так:

Остается вариант упорядочивать выхлоп выборки по другому полю, например, по priority.

Потому что:

Вообще, я думаю, что трогать autoincrement некрасиво, вдобавок я использую django orm, а это значит, что при наличии FK на запись, все ссылки при сдвиге сломаются.

Так что не придумывай проблему себе и тем, кто будет этот код после тебя рефакторить, а то можешь умереть от икания, когда тебя будут вспоминать бодрым словом. Серьёзно.

commit ★★
()

По другому полю. Изначально задавать значение как в васике - с шагом 10. Тогда можно будет легко вставлять промежуточные строки (до 9 шт.)

ziemin ★★
()
Ответ на: комментарий от commit

Дело в том, что идет речь о парсере предложений, выдернутых из кучи docx, pdf, odt и еще пачки форматов. Используется nltk, который иногда спотыкается и не разбивает текст на предложения правильно, поэтому юзеру нужно оставить возможность склеивать/разбивать их.

Знатный треш и угар.

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

division_hell
() автор топика
Ответ на: комментарий от division_hell

Меня вот коробит от идеи сдвигать priority при каждой вставке

Ого. А от идеи двигать автоинкременты управляемые БД не коробит?

commit ★★
()
Ответ на: комментарий от commit

Ого. А от идеи двигать автоинкременты управляемые БД не коробит?

А я их что ли двигал irl? Это просто мысли вслух. Да и дело вообще не в этом. Меня интересует, есть ли возможность хранить данные так, чтобы не было необходимости что-то двигать.

Один файл весит ~1-10мб. В нем тысячи/десятки тысяч предложений.

Изначально я вообще не хотел ничего разбивать, а хранить offset'ы предложений, но это плохо подходит из-за специфики и дальнейших проблем с индексацией.

division_hell
() автор топика
Ответ на: комментарий от division_hell

Проблема в том, что ты выбрал неправильную DB под задачу. Или неверную презентацию данных в рамках SQL. Тебе нужно что-то вроде linked-list.

Мопед не мой, но глянь: http://stackoverflow.com/questions/65205/linked-list-in-sql

beastie ★★★★★
()
Ответ на: комментарий от beastie

Проблема в том, что ты выбрал неправильную DB под задачу.

А какая DB лучше подойдет? Хранить нужно по ТЗ 1+ гигов.

division_hell
() автор топика
Ответ на: комментарий от division_hell

1гб вообще не объём для существующих субд.

AnDoR ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.