?

Журнал от Объекта

Previous Entry Share Flag Next Entry
Базы данных и hard-delete
Default
object
Statement: "Avoid soft deletes".
And response: "Don’t delete. Just don’t".

Я, конечно, принадлежу к лагерю Уди Дахана.



  • 1
Ага, "real world doesn't cascade" это хорошая формулировка.

Да в общем-то и doesn't delete.

это ничего не значащая глупая хуйня

Почему? Это такой очевидный всем, кто пишет enterprise database driven системы труизм, неплохо сформулированный. Я не стану спорить с "глупой хуйней", т.к. это Ваше личное мнение, но почему же "ничего не значащая"?

Re: Відповідь на ваш коментар...

ок
объясните мне, пожалуйста, что это значит
я не понял

Re: Відповідь на ваш коментар...

Ну лучше начать с того, что сказал выше Вагиф: real world doesn't delete. Из базы данных удалять ничего не нужно. Когда человек отменяет заказ, это не означает, что о нем нужно забыть и выкинуть его из базы данных, это означает, что его нужно отметить как отмененный. И то же самое верно про большинство вещей, с которыми приходится иметь дело в т.н. enterprise applications. Потому что есть требования аудита, статистики да и вообще интуитивно понятно, что хотя бы для поиска багов бывает полезно иметь возможность увидеть что происходило в системе месяц назад. Поэтому на самом деле зачастую приходится знать не только что заказ был удален, но *когда* он был удален, и т.п. Там в одной из статей правильная мысль о том, что нужно думать о действиях, а не о данных. Ну и тоже самое с каскадами (не знаю как по-русски). Даже если надо что-то удалить, это совершенно не значит, что нужно удалить то, что на это ссылается. Так что даже если какие-то данные удалить можно, то из-за referrential integrity их удалять нельзя, т.к. real world doesn't cascade. Это ёмкая и броская фраза, которая напоминает нам, что базами данных мы пользуемся не потому, что это хорошая абстракция, а потому, что лучше ничего нет да и привыкли. А вообще реляционные бд -- это такая странная в пост-ООП мире абстракция, призванная решить проблему, которая уже 10 лет как неактуальная (дорогая и ограниченная по объему оперативная память).

Re: Відповідь на ваш коментар...

Удаление и отмена - это разные вещи прежде всего с точки зрения бизнес-логики.
Требования аудита и статистики тоже не должны быть абстрактными, логирование изменений надо добавлять по требованию, а не имплементировать по умолчанию.
"Так что даже если какие-то данные удалить можно, то из-за referrential integrity их удалять нельзя, т.к. real world doesn't cascade." - круто, теперь я понял, что значит фраза real world doesn't cascade. Значит, нельзя, потому что real world doesn't cascade. Очень фукнциональный принцип.Абстракция - это не реляционные базы данных, а мир пост-ООП и real world doesn't cascade. А еще real world can't be backed-up - как там в мире пост-ООП с этим дела обстоят?

Edited at 2009-09-01 04:45 pm (UTC)

Re: Відповідь на ваш коментар...

Я только понял, что Вы всё это считаете глупостями и, видимо, слишком общими утверждениями. А почему не понял.
Естественно, никто не говорит, что *всё* нужно логировать, но часто -- нужно. Я уже несколько раз сталкивался с тем, что вещи просто удалялись или даже не удалялись, а менялось состояние на "удалено", а потом все спохватывались, что нужно было знать *когда*. Я сейчас сделал поиск на "delete" в запросах нашей системы (средних размеров, скажем) и нашёл 10, из которых, я думаю, только 1 имеет право на существование, остальные либо странные хаки для перевода данных из одного формата в другой, либо старые, не используемые куски, которые забыли удалить.
"Абстракция", кстати, это не ругательство.

Re: Відповідь на ваш коментар...

ничего не удалять - это и есть логировать все, если вы сталкивались с тем, что человеку не мог узнать "когда" запись была помечена как удаленная - это значит только то, что структуру изначально проектировал не просто убежденный сторонник IsDeleted, а еще к тому же и идиот
"Я только понял, что Вы всё это считаете глупостями и, видимо, слишком общими утверждениями. А почему не понял"
ну вы же не привели мне конкретных примеров, для которых действует принцип real world doesn't cascade

Re: Відповідь на ваш коментар...

RTFA?

Let’s say our marketing department decides to delete an item from the catalog. Should all previous orders containing that item just disappear? And cascading farther, should all invoices for those orders be deleted as well? Going on, would we have to redo the company’s profit and loss statements?

Re: Відповідь на ваш коментар...

ну вот я не понимаю, на кого расчитана эта хуйня
конечно, удаление записей из справочников не может быть каскадным, ну это вообще как-то странно писать сейчас, чувствую себя на лекции у первокурсников
каскадное удаление существует для parent-child иерархий

Re: Відповідь на ваш коментар...

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

Re: Відповідь на ваш коментар...

Поддерживаю, отсылки к "реальному миру" смешны, т.к. чтобы все было "реально", надо узелки завязывать или там зарубки делать, а не с базами данных возиться. Для того єто все и придумывалось, чтобы уйти от ограничений "реального мира".

Другое дело, что в большинстве бизнес-задач (по крайней мере, с которыми я сталкивался) действительно удобнее отказаться от удаления заранее. Но я бы назвал такое распространенным частным случаем, а не общим правилом.

По поводу же каскадности не понял - если она становится "бутылочным горлышком", давно придуманы более удобные в єтом смысле иерархические механизмы, чем parent/child (nested sets, например), а в современных СУБД так и вовсе встроенная поддержка деревьев есть. Хотя вообще, если дерево является основой структуры, єто повод задуматься, а нужно действительно в таком проекте реляционные системы использовать.

И в какой-то момент

начинаются стоны: а почему добавить order занумает 15 минут? А ты смотришь в таблицу а там миллион-триллионов строк, 9/10 которых машинно-отмены как obsolete, давно забытой процедурой.

Re: И в какой-то момент

Ну для этого есть partitioning, например.

Re: И в какой-то момент

А кто тебе сказал, что будет легко?

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

это удивительно, о какой ерунде могут так самозабвенно спорить серьезные, вроде бы, люди

Второй чудак всё просто описал. В том сценарии что-то стирать в базе данных - просто неправильно.

  • 1