Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
пометка на удаление
|
|||
|---|---|---|---|
|
#18+
Хотелось бы увидеть кто-как организует пометку на удаление (логическое удаление) с возможностью последующего восстановления. Для начала интересны следующие вопросы: 1) организация каскадного удаления(пометки) и восстановления. 2)следует ли давать возможность восстанавливать запись если она была помечена по каскаду (т.е. пометка не на 1-ом уровне, а на уровне N). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.12.2004, 09:53 |
|
||
|
пометка на удаление
|
|||
|---|---|---|---|
|
#18+
Роман ДынникХотелось бы увидеть кто-как организует пометку на удаление (логическое удаление) с возможностью последующего восстановления. А как кроме установки флажка - удалено да/нет можно сделать? Флажок конечно может быть разным по исполнению, но суть одна. Роман ДынникДля начала интересны следующие вопросы: 1) организация каскадного удаления(пометки) и восстановления. 2)следует ли давать возможность восстанавливать запись если она была помечена по каскаду (т.е. пометка не на 1-ом уровне, а на уровне N). А не запутаешься сам? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.12.2004, 10:06 |
|
||
|
пометка на удаление
|
|||
|---|---|---|---|
|
#18+
>>>А не запутаешься сам Поэтому и топик создал. Posted via ActualForum NNTP Server 1.1 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.12.2004, 10:11 |
|
||
|
пометка на удаление
|
|||
|---|---|---|---|
|
#18+
А зачем вообще удалять "логически" дочерние данные? Если "удалены" родители, они и так не влияют ни на что. По крайней мере не должны. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.12.2004, 10:18 |
|
||
|
пометка на удаление
|
|||
|---|---|---|---|
|
#18+
1) Делаешь view select * from my_table where deleted = 'N' и во всех запросах используешь именно её 2) Технически с использованием 1) вопрос снимается, организационно - ориентируйся по бизнес-логике ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.12.2004, 10:24 |
|
||
|
пометка на удаление
|
|||
|---|---|---|---|
|
#18+
например, если дочерние (по физической модели) записи предсталяют собой записи из справочника, надо запретить выбор(в смысле выбор строки из справочника в интерфейсе для другого объекта) таких записей из него. Posted via ActualForum NNTP Server 1.1 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.12.2004, 10:25 |
|
||
|
пометка на удаление
|
|||
|---|---|---|---|
|
#18+
У меня в базовом объекте есть поле Deleted bit Если ставлю = 1, то считается удаленным и на клиенте не отображается. А так как все данные объекта можно вытащить из базы только если обратиться к самому объекту, то вопрос с дочерними данными отпадает А вот когда физически объект удаляется, то раскручиваясь по иерархии вызываются все процедуры удаления объекта и чистятся все его дочерние данные -------------------- Не учи отца и баста! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.12.2004, 10:35 |
|
||
|
пометка на удаление
|
|||
|---|---|---|---|
|
#18+
Роман Дынникнапример, если дочерние (по физической модели) записи предсталяют собой записи из справочника Как это? Справочник - дочерний к несправочнику? Пример приведи, плиз. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.12.2004, 10:39 |
|
||
|
пометка на удаление
|
|||
|---|---|---|---|
|
#18+
А так как все данные объекта можно вытащить из базы только если обратиться к самому объекту, то вопрос с дочерними данными отпадает Объясняю: справочник сотрудников, справочник должностей сотрудников. Логически удаляется должность. (Блин, пример не очень удачный, но суть думаю будет понятна). сотрудники с удаляемой должностью являются по сути(физически) дочерними записями по отношению к справочнику должностей. Логически же это естественно не один объект. Posted via ActualForum NNTP Server 1.1 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.12.2004, 10:44 |
|
||
|
пометка на удаление
|
|||
|---|---|---|---|
|
#18+
Роман ДынникОбъясняю: справочник сотрудников, справочник должностей сотрудников. Не хотелось бы поднимать флейм по поводу - что есть справочник. С моей точки зрения справочник сотрудников - это не справочник. По сути. ИМХО, в данном примере не прописано бизнес-правило удаления должности. Потому что не может быть на предприятии человека без должности, или с несуществующей должностью. Простым удалением, даже "логическим" - этоне описать. ИМХО, опять же. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.12.2004, 10:56 |
|
||
|
пометка на удаление
|
|||
|---|---|---|---|
|
#18+
авторОбъясняю: справочник сотрудников, справочник должностей сотрудников. Логически удаляется должность. (Блин, пример не очень удачный, но суть думаю будет понятна). сотрудники с удаляемой должностью являются по сути(физически) дочерними записями по отношению к справочнику должностей. Логически же это естественно не один объект. Нехороший пример - пока есть сотрудники с этой должностью, должность удалять нельзя. Я вообще нигде не имею никаких способов для псевдоудаления - просто не вижу смысла. -- Tygra's -- ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.12.2004, 10:57 |
|
||
|
пометка на удаление
|
|||
|---|---|---|---|
|
#18+
Для такой ситуации у меня перед удалением проверяется нет ли ссылок других объектов в атрибутах удаляемого, если есть то выводится ругань и указывается ссылающийся объект ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.12.2004, 11:02 |
|
||
|
пометка на удаление
|
|||
|---|---|---|---|
|
#18+
я сказал что пример не очень удачный. Posted via ActualForum NNTP Server 1.1 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.12.2004, 11:16 |
|
||
|
пометка на удаление
|
|||
|---|---|---|---|
|
#18+
А других то не бывает. Либо как в этом примере, либо запись одна, ни с чем не связана - а тогда пофиг, есть она или нет, можно и удалить, можно пометить, одно и то же получится -- Tygra's -- ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.12.2004, 12:52 |
|
||
|
пометка на удаление
|
|||
|---|---|---|---|
|
#18+
tygraА других то не бывает. Либо как в этом примере, либо запись одна, ни с чем не связана - а тогда пофиг, есть она или нет, можно и удалить, можно пометить, одно и то же получится -- Tygra's -- Поддерживаю. Тут и изобретать ничего не надо - FOREIGN KEY и уже удалять записи, на которые ссылаются другие обьекты, нельзя. Для более сложных случаев спасет триггер. Для случаев же, когда в клиентском приложении хочется не показывать все записи, которые не актуальны на текущий момент делается граммотный фильтр, в котором пользователь может сам выбрать что ему показывать, а что скрывать. По расчетам/отчетам и скрывать ничего не надо - если записи потеряли актуальность и ушли в архив, они по любому себя не проявят в бизнес-логике никак. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.12.2004, 15:21 |
|
||
|
пометка на удаление
|
|||
|---|---|---|---|
|
#18+
> справочник сотрудников, справочник должностей сотрудников. > Логически удаляется должность. > сотрудники с удаляемой должностью являются по сути(физически) дочерними > записями по отношению к справочнику должностей. Логически же это > естественно не один объект. Хм... пример действительно не очень удачный. Не факт, что сотрудника нужно маркировать удаленным: например, он может получить другую должность из оставшихся. Imho логическое удаление связанных записей должно происходить на основании метаописания связей, типов связей и типов событий (что-то можно удалять автоматом, что-то - только оператору). В приведенном Вами примере типом события может быть "сокращение штатов" (или какая там у Вас классификация событий?), должности штатного расписания и соответствующие записи в таблице связей штатного расписания и сотрудников маркируются удаленными, сотрудники, занимающие эти должности - ставятся в очередь обработки оператором. Восстановление в данном случае будет представлять собой создание новых записей вместо помеченных удаленными на основании журнала истории изменений (часть котого будет заполнена автоматом, часть - оператором (в смысле, тоже не руками, но записи будут сгенерированы действиями оператора)). Восстановление будет описано в журнале изменений как откат. Я правильно понял задачу? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.12.2004, 16:35 |
|
||
|
пометка на удаление
|
|||
|---|---|---|---|
|
#18+
Логическое удаление нужно ! Очень нужно ! Чтоб запретить использовать к-л сущность, которую нельзя удалять физически. Например старый товар, по которому были продажи но которого уже нет и не будет. Удалять нельзя, но он путается под ногами. Признак "удалён" помогает не отображать лишнюю инфу. Эту пометку можно сделать дифференцированой т.е. с нескольких составляющих, например: запрет закупки, запрет продажи, запрет прочих операций. Я думаю смысл понятен... ИМХО, такой признак нужен почти у всех (!) сущностей. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.12.2004, 12:07 |
|
||
|
пометка на удаление
|
|||
|---|---|---|---|
|
#18+
LSVЛогическое удаление нужно ! Очень нужно ! Чтоб запретить использовать к-л сущность, которую нельзя удалять физически. Например старый товар, по которому были продажи но которого уже нет и не будет. Удалять нельзя, но он путается под ногами. Признак "удалён" помогает не отображать лишнюю инфу. Эту пометку можно сделать дифференцированой т.е. с нескольких составляющих, например: запрет закупки, запрет продажи, запрет прочих операций.Так это скорее не удаление, а признак актуальности. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.12.2004, 12:09 |
|
||
|
пометка на удаление
|
|||
|---|---|---|---|
|
#18+
по-моему предыдущий автор гипертрофировал понятие "удаление"... удаление уже стало чем-то другим... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.12.2004, 12:10 |
|
||
|
|
start [/forum/topic.php?fid=32&msg=32849074&tid=1546119]: |
0ms |
get settings: |
8ms |
get forum list: |
20ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
36ms |
get topic data: |
13ms |
get forum data: |
3ms |
get page messages: |
86ms |
get tp. blocked users: |
2ms |
| others: | 214ms |
| total: | 388ms |
| 0 / 0 |
