Спустя 6 часов, 2 минуты, 51 секунда (28.10.2009 - 08:48) sergeiss написал(а):
Записи не удаляются физически из БД по команде DELETE, а помечаются на удаление. Для чистки таблиц от таких записей надо выполнять специальные команды.
В Постгре это VACUUM.
В MySQL тоже что-то есть.
В Постгре это VACUUM.
В MySQL тоже что-то есть.
Спустя 7 часов, 40 минут, 39 секунд (28.10.2009 - 16:29) hozer написал(а):
А можешь точнее подсказать как это сделать в SQLite? А то я что-то не могу найти.
Спустя 6 часов, 7 минут, 28 секунд (28.10.2009 - 22:36) haZe написал(а):
Ухты! Очень интересный факт открыли для меня!
То есть в теории, я это никогда не делал, получается у меня база захламлена "не удаленными" записями? Но я их не вижу.. 0_о
То есть в теории, я это никогда не делал, получается у меня база захламлена "не удаленными" записями? Но я их не вижу.. 0_о
Спустя 37 минут, 22 секунды (28.10.2009 - 23:13) Winston написал(а):
| Цитата (sergeiss @ 28.10.2009 - 08:48) |
| Записи не удаляются физически из БД по команде DELETE, а помечаются на удаление. |
И я чет не понял
У меня с помощью DELETE удаляется с базы то что мне нужно. Спустя 2 часа, 18 минут, 53 секунды (29.10.2009 - 01:32) kirik написал(а):
| Цитата (PHPprogramer @ 28.10.2009 - 15:13) |
| У меня с помощью DELETE удаляется с базы то что мне нужно. |
Откуда знаешь?
Если ты ее не видишь, это не значит что ее нет | Цитата (haZe @ 28.10.2009 - 14:36) |
| получается у меня база захламлена "не удаленными" записями? |
Даже больше можно сказать, после удаления файла с жесткого диска он тоже не удаляется сразу, а лишь помечается на удаление. Удаляется полностью, только когда ты запишешь что-то сверху (если конечно то, что ты будешь писать ФС решит записать на ту область диска, где лежит старый файл).
Спустя 12 минут, 57 секунд (29.10.2009 - 01:45) twin написал(а):
| Цитата |
| Записи не удаляются физически из БД по команде DELETE, а помечаются на удаление. |
Не знаю как в постгре и склайте, но в мускуле строки, удаленные DELETE физически в файле не хранятся. Правда иногда, при интенсивной работе с таблицей, её желательно оптимизировать, что бы упорядочить пространство.
Делается это запросом OPTIMIZE TABLE.
Но это не то, о чем речь.
Спустя 6 часов, 59 минут, 22 секунды (29.10.2009 - 08:45) Michael написал(а):
То же вроде и книгу прочел нехуденькую, но не встречал ТЗ на дополнит. удаление.
Проверил на MyISAM
1) добавил 3 записи (латиница)
2) отключил сервер + просмотрел блокнотом файл - 3 записи (они - те что вводил)
3) включил сервер + удалил 2-ю запись
4) отключил сервер + просмотрел блокнотом - 2 записи по бокам те же, а среднюю шифронуло, но она есть (видимо пометка изменила представление)
объем файла не уменьшился.
Надо поразбираться ...
Проверил на MyISAM
1) добавил 3 записи (латиница)
2) отключил сервер + просмотрел блокнотом файл - 3 записи (они - те что вводил)
3) включил сервер + удалил 2-ю запись
4) отключил сервер + просмотрел блокнотом - 2 записи по бокам те же, а среднюю шифронуло, но она есть (видимо пометка изменила представление)
объем файла не уменьшился.
Надо поразбираться ...
Спустя 28 минут, 4 секунды (29.10.2009 - 09:13) sergeiss написал(а):
| Цитата (twin @ 29.10.2009 - 02:45) |
| Не знаю как в постгре и склайте, но в мускуле строки, удаленные DELETE физически в файле не хранятся. |
Вот тут позволь с тобой категорически не согласиться!
В любой БД, и MySQL не исключение, удаленные записи помечаются как неиспользуемые, и поверх них могут быть записаны новые данные. Но пока ты не запустишь специальную команду, эти старые данные будут именно физически присутствовать в таблице.
Другой вопрос, что оптимизацию с упаковкой имеет смысл проводить только тогда, когда удаляешь сразу много (типа, как в моем проекте со статистикой раз в неделю удаляются данные старше 15 дней). Именно для оптимизации дискового пространства. Потому что если постоянно что-то удаляешь, но и постоянно же что-то пишешь (и количество удаленых-добавленных примерно равны), то тогда и таблица не будет расти.
Кстати. В том же Постгре можно как просто оптимизировать пространство, не изменяя размер таблиц, так и упаковать их, освободив много места на диске.
Вот только фигня в том, что насчет SQLite я просто не знаю, как это сделать. Но эта фича должна быть обязательно.
Спустя 8 минут, 13 секунд (29.10.2009 - 09:21) sergeiss написал(а):
О, йес! Нашел!
И тут всё сделано по уму, почти как и в Постгре!
http://sb-money.ru/sqlite.php?page=61 - вот тут описание упаковки таблиц в SQLite. Команда (судя по описанию) почти что идентична той, что имеется в Постгре.
В Постгре можно дать команду для индивидуальной таблицы, а тут - нельзя.
И тут всё сделано по уму, почти как и в Постгре!
http://sb-money.ru/sqlite.php?page=61 - вот тут описание упаковки таблиц в SQLite. Команда (судя по описанию) почти что идентична той, что имеется в Постгре.
В Постгре можно дать команду для индивидуальной таблицы, а тут - нельзя.
Спустя 20 минут, 25 секунд (29.10.2009 - 09:41) Michael написал(а):
Да, sergeiss, все правильно говорит.
Проверил для MySQL:
1) Если просто удалять DELETE то только помечаются, физически не удаляются
2) Если выполнить OPTIMIZE TABLE, то помеченные на удаление физически удалятся
3) Если выполнить INSERT и в таблице имеются помеченные на удаление - то
пишется вместо них
В принципе если баланс вставка - удаление соблюдается, то можно не мудрить, как twin и говорил.
Только если много удалять и мало добавлять, то OPTIMIZE TABLE.
Хотя помню один из экспертов раньше писал, что он в среднем каждый 5-ый запрос на модификацию сопровождает запросом OPTIMIZE TABLE.
Проверил для MySQL:
1) Если просто удалять DELETE то только помечаются, физически не удаляются
2) Если выполнить OPTIMIZE TABLE, то помеченные на удаление физически удалятся
3) Если выполнить INSERT и в таблице имеются помеченные на удаление - то
пишется вместо них
В принципе если баланс вставка - удаление соблюдается, то можно не мудрить, как twin и говорил.
Только если много удалять и мало добавлять, то OPTIMIZE TABLE.
Хотя помню один из экспертов раньше писал, что он в среднем каждый 5-ый запрос на модификацию сопровождает запросом OPTIMIZE TABLE.
Спустя 2 часа, 48 минут, 48 секунд (29.10.2009 - 12:30) twin написал(а):
Ну что вы тут сказки то рассказываете...
Ничего там не хранится физически, удаляется все.
Другое дело, что сохраняются использованные ключи при автоинкременте, это другой вопрос, но сами данные стираются, а не помечаются вовсе.
Если под "строками" понимать "пустые строки", то можно с большой натяжкой сказать, что это такая пометка. Пустые строки с ключами там есть. Но автор то спросил:
Ничего там не хранится физически, удаляется все.
Другое дело, что сохраняются использованные ключи при автоинкременте, это другой вопрос, но сами данные стираются, а не помечаются вовсе.
Если под "строками" понимать "пустые строки", то можно с большой натяжкой сказать, что это такая пометка. Пустые строки с ключами там есть. Но автор то спросил:
| Цитата |
| Но в самом файле базы данных (sqlite) эта запись остаётся. Как это понимать? |
Нет там никаких записей. В мускуле точно нет. И согласитесь, "пустая строка" и "помеченная строка" - несколько разные понятия.
Спустя 16 минут, 16 секунд (29.10.2009 - 12:46) Michael написал(а):
twin, для MyISAM чисто физически место в БД не освобождается после delete.
(в принципе это сделано для скорости наверное - чтоб не пододвигать последующие записи на место удаленной)
Логически её там нет, что select и выдаст.
Кстати как в таблицах innoDB не знаю - не знаю как проверить.
(в принципе это сделано для скорости наверное - чтоб не пододвигать последующие записи на место удаленной)
Логически её там нет, что select и выдаст.
Кстати как в таблицах innoDB не знаю - не знаю как проверить.
Спустя 15 минут, 36 секунд (29.10.2009 - 13:02) twin написал(а):
Мы может о разных вещах говорим...
| Цитата |
| для MyISAM чисто физически место в БД не освобождается после delete. |
Что имеется ввиду под "место в БД"?
Данные в строке не хранятся физически. Хранятся только идентификаторы. Если это считать пометкой, я соглашусь. Но имелось ввиду совсем другое.
Спустя 11 минут, 53 секунды (29.10.2009 - 13:14) sergeiss написал(а):
| Цитата (twin @ 29.10.2009 - 13:30) |
| Ну что вы тут сказки то рассказываете... Ничего там не хранится физически, удаляется все. |
Экий ты "несогласный"
Сначала данные помечаются на удаление. Размер файла, содержащего таблицу, не изменяется.
Затем это место может быть занято другими (новыми) записями. Размер файла не меняется.
И это место можно "отдать" файловой системе, что очень полезно в случае удаления большого объема данных. Это как раз и делают OPTIMIZE в MySQL и VACUUM в Postgre и в SQLite. Фактически, таблица создается заново с использованием тех записей, которые не были помечены на удаление.
И дабы больше об этом не спорить, приведу фрагмент из хэлпа по MySQL:
| Код |
| Чтобы объединить фрагментированные записи и избавиться от потерь пространства, происходящих из-за удаления и обновления записей, нужно запустить myisamchk в режиме восстановления: shell> myisamchk -r tbl_name Такую же оптимизацию таблицы можно произвести, используя команду SQL OPTIMIZE TABLE. OPTIMIZE TABLE выполняет ремонт таблицы и анализ ключей, а также сортирует дерево индексов для ускорения поиска ключей. Вдобавок сводится на нет нежелательное взаимодействие между утилитой и сервером, поскольку при использовании OPTIMIZE TABLE работу выполняет сам сервер. Обращайтесь к разделу See section 4.5.1 |
Спустя 26 минут, 10 секунд (29.10.2009 - 13:40) twin написал(а):
Ну посыпаю башку отходами котельной...
В очередной раз убеждаясь, что нельзя верить никому, даже признанным авторитетам. Этот вопрос муссировался в одном диспуте и один довольно крупный специалист объяснял именно так.
Полез, проверил сам - видимо вы правы. Действительно хрень какая то...
В очередной раз убеждаясь, что нельзя верить никому, даже признанным авторитетам. Этот вопрос муссировался в одном диспуте и один довольно крупный специалист объяснял именно так.
Полез, проверил сам - видимо вы правы. Действительно хрень какая то...
Спустя 4 минуты, 31 секунда (29.10.2009 - 13:45) sergeiss написал(а):
| Цитата (twin @ 29.10.2009 - 14:40) |
| В очередной раз убеждаясь, что нельзя верить никому, даже признанным авторитетам. |
Я даже себе не всегда верю в таких вопросах, перепроверяю иногда
