История изменений
Исправление
stevejobs,
(текущая версия)
:
тут ответ из двух частей,
1) update все равно быстрей delete
2) автовакуум это вообще хрен знает что такое, написанное на говноязыке (на си или си++) и поэтому неизменяемое для всех кроме авторов postgresql, повлиять на которое можно двумя с половиной параметрами. А свой собственный код ты можешь поменять как хочешь под конкретную задачу.
3) и уж тем более автовакуум не будет делать тебе кластерный бэкап =)
4) у тебя совершенно не обязательно там postgres, может быть древнючий mysql, в котором полный ад
5) но САМОЕ главное, ты не всегда технически можешь справиться со сложностью удаления записей в БД.
Например, у тебя софтина занимающаяся управлением корпорацией, и есть сущность (и соответственно таблица) «Организация». Сущность Организация связана с другими таблицами, они - с другими, полный граф может занимать сотни таблиц. Причем эти таблицы могут быть сделаны школьниками совершенно без знания о реляционных бд, без foreign keys, unique constraints, без возможности делать вменяемые джойны, каскады, и так далее.
Далее, ты хочешь удалить одну Организацию, и теперь вообще ХЗ как ее удалить, не поломав все-все содержимое БД, это ОЧЕНЬ сложно. Поэтому вместо физического удаления такая Организация обычно помечается как историческая, выставлением флага типа deleted (или скорее там ссылка на таблицу с описанием как именно она deleted, н-р «саму организацию удалить, а дочек оставить»)
Но однажды все это начнет занимать слишком много места, и кому-то захочется прямо физически удалять записи.
То есть вполне вероятно, что «удалаляльщик записей» будет совершенно отдельной софтиной, написанной другими людьми в рамках другого проекта, и будет рабоать например как периодический Garbage Collector поверх основной софтины.
Можно предвосхитить события, и такую «архитектуру» планировать заранее, т.е. для каждого сервиса делать в сопровождение сервис timed GC.
И никакая автоматика встроенная в БД тут не поможет, если уж ты сам не знаешь что там и как происходит, как с этим разберется автоматика?
Исправление
stevejobs,
:
тут ответ из двух частей,
1) update все равно быстрей delete
2) автовакуум это вообще хрен знает что такое, написанное на говноязыке (на си или си++) и поэтому неизменяемое для всех кроме авторов postgresql, повлиять на которое можно двумя с половиной параметрами. А свой собственный код ты можешь поменять как хочешь под конкретную задачу.
3) и уж тем более автовакуум не будет делать тебе кластерный бэкап =)
4) у тебя совершенно не обязательно там postgres, может быть древнючий mysql, в котором полный ад
5) но САМОЕ главное, ты не всегда технически можешь справиться со сложностью удаления записей в БД.
Например, у тебя софтина занимающаяся управлением корпорацией, и есть сущность (и соответственно таблица) «Организация». Сущность Организация связана с другими таблицами, они - с другими, полный граф может занимать сотни таблиц. Причем эти таблицы могут быть сделаны школьниками совершенно без знания о реляционных бд, без foreign keys, unique constraints, без возможности делать вменяемые джойны, каскады, и так далее.
Далее, ты хочешь удалить одну Организацию, и теперь вообще ХЗ как ее удалить, не поломав все-все содержимое БД, это ОЧЕНЬ сложно. Поэтому вместо физического удаления такая Организация обычно помечается как историческая, выставлением флага типа deleted (или скорее там ссылка на таблицу с описанием как именно она deleted, н-р «саму организацию удалить, а дочек оставить»)
Но однажды все это начнет занимать слишком много места, и кому-то захочется прямо физически удалять записи.
То есть вполне вероятно, что «удалаляльщик записей» будет совершенно отдельной софтиной, написанной другими людьми в рамках другого проекта, и будет рабоать например как периодический Garbage Collector поверх основной софтины.
Можно предвосхитить события, и такую «архитектуру» планировать заранее, т.е. для каждого сервиса делать в сопровождение сервис timed GC
Исходная версия
stevejobs,
:
тут ответ из двух частей,
1) update все равно быстрей delete
2) автовакуум это вообще хрен знает что такое, написанное на говноязыке (на си или си++) и поэтому неизменяемое для всех кроме авторов postgresql, повлиять на которое можно двумя с половиной параметрами. А свой собственный код ты можешь поменять как хочешь под конкретную задачу.
3) и уж тем более автовакуум не будет делать тебе кластерный бэкап =)
2) у тебя совершенно не обязательно там postgres, может быть древнючий mysql, в котором полный ад
3) но САМОЕ главное, ты не всегда технически можешь справиться со сложностью удаления записей в БД.
Например, у тебя софтина занимающаяся управлением корпорацией, и есть сущность (и соответственно таблица) «Организация». Сущность Организация связана с другими таблицами, они - с другими, полный граф может занимать сотни таблиц. Причем эти таблицы могут быть сделаны школьниками совершенно без знания о реляционных бд, без foreign keys, unique constraints, без возможности делать вменяемые джойны, каскады, и так далее.
Далее, ты хочешь удалить одну Организацию, и теперь вообще ХЗ как ее удалить, не поломав все-все содержимое БД, это ОЧЕНЬ сложно. Поэтому вместо физического удаления такая Организация обычно помечается как историческая, выставлением флага типа deleted (или скорее там ссылка на таблицу с описанием как именно она deleted, н-р «саму организацию удалить, а дочек оставить»)
Но однажды все это начнет занимать слишком много места, и кому-то захочется прямо физически удалять записи.
То есть вполне вероятно, что «удалаляльщик записей» будет совершенно отдельной софтиной, написанной другими людьми в рамках другого проекта, и будет рабоать например как периодический Garbage Collector поверх основной софтины.
Можно предвосхитить события, и такую «архитектуру» планировать заранее, т.е. для каждого сервиса делать в сопровождение сервис timed GC