Наверное все знают, что удалять строки в БД - не есть хорошо. Намного лучше пометить строку как удаленную, а позже, при новом инсерте - заапдейтить одну из удаленных строк. Я тоже всегда так считал, и вот, при разработке нового движка, решил реализовать данный механизм. Но почти сразу натолкнулся на мысль, что это может привести к определенным трудностям. К примеру, имеем товар с айди=1. Роботы проиндексили, люди понаделали закладок - ссылка пашет. Тут мы удаляем товар (помечаем строку удаленной), и пишем вместо данной строки новый товар. В итоге на месте ожидаемого товара будет совсем другой. Навскидку подумалось создавать некий уникальный идентификатор товара, и вытаскивать строки не по айди, а именно по этому идентификатору. Но это уже другая задача, и ее реализация, без накладки на производительность, будет непростой. В итоге получаем дилемму, или не_удалять, иметь целостность индексов и быстрый поиск в БД, но меньшую скорость при апдейте базы , или удалять, херя по чуть чуть базу, но иметь ту же скорость во всех операциях с БД. Какие идеи по данной теме, может кто уже решал эту проблему?
Я не знал, и не знаю... Знаю за то что дешевле забивать гвозди кирпичом (его можно бесплатно найти на улице) вместо того чтоб покупать молоток.
тогда вы, наверное, не знаете, что при частом удалении строк, и больших пробелах в индексируемых полях вы херите на нет вашы индексы. т.е. пользы от них практически нет. ну а что такое индексы и что будет, если их не будет я думаю рассказывать не стоит. any other ideas?
портиться жесткий диск. Почему индексы должны теряться? Это что, Маша-растеряша? Это реляционная БД! Добавьте тысячу строк и удалите, а потом вставьте новую запись и посмотрите на id. Индексы могут потеряться, если таблица crashed, лечиться repairом.
лол) советую почитать о том, как работает поиск по индексам, как они строятся, и вообще про функционал индексов в MySQL. вы не в теме, товарищ.
Тьфу блин %) переклинило на идентификаторы. Извиняюсь )) Тогда вопрос, чем можно объяснить нарушение индексов при частом удалении?
creage Наверное стоит задаться вопросом: какая операция будет вызываться чаще? Если БД обновляется N-раз в сутки а просматривается всего N/100 раз, то становится понятно, что выбрать
2Kreker не нарушение, а эффективность их использования. смысл в том, что при нарушении последовательности ключей индекса скорость поиска по нему увеличивается. при больших провалах в последовательности практически пропадает смысл использования индекса. а при сложных и больших выборках это большой минус производительности. у меня есть (была) база, где из-за такого недочета 10 строк выбирались порядка 25 секунд. очень долго искал дырку, пока не прочел про индексы, и не переработал архитектуру.
мною скорее всего руководит желание создать безотказную устойчивую систему, которая сможет работать при любых условиях и нагрузках. для маленьких проектов этот вопрос наверное вообще не актуален. давайте поставим вопрос иначе - если бы перед вами встала такая задача - как бы вы ее решили?
Что есть частое ? (вот когда каждое открытие страницы коих может быть млн в день то это частое) В случае с интернет магазином (о магазине идёт речь как я понял и о его таблицы с товарами) ни о каком "частом" речи не идёт, тут достаточно удалять строку и автоматом сразу делать Optimize Table чтоб восстановить всё что "похерили" восстановить. (если уж такая паранойя с потерянными индексами вас приследует)
Для больших отказоустойчивых систем отказываются от мускула, ага. Что ва мешает перестраивать индекс раз в две недели например, автоматически?
creage А если записи помечать, как удаленные, это уже не будет считаться пробелами, ога И все выборки переписывать, добавляя в них ненужное условие, это тоже очень здорово. Индекс - это индекс. Хранится в виде дерева. Скорость работы от конкретных значений никак не зависит. Раз в год можно выполнить OPTIMIZE TABLE и все физические дыры исчезнут. Но скорее всего, они исчезнут раньше, при внутреннем перестроении индекса, которое происходит автоматически при добавлении узлов в дерево.
creage Ссылку на источник, плиз. Первый раз слышу такие страсти. Смею утверждать, что проблема была совсем в другом... как выглядел запрос?
Индекс - штука нелинейная, а древовидная. Индекс по числовым полям по сути своей не может потерять в скорости, даже если у него два миллиона строк потеряно между первой и последней записью.
Вчера долго дискутировали на данную тему с одним товарищем. В итоге он меня убедил, что не_удалять записи стоит только в случае, если данная запись тебе может пригодится в будущем, типа восстановление. Но записывать на ее место другую строку - неправильно. Всем спасибо за комментарии, вопрос исчерпан. Надеюсь, кому-то тоже будет полезно)
У нас записи не удаляются по другим причинам - может банально разьехаться статистика, отчетность, et cetera. Надо всегда плясать от задачи, и все.