Обработка Удаленные данные в приложениях

Question

Предположим, что вы пишете простое приложение. Модель состоит в том, что «проект» имеет «категорию». Категория проекта можно редактировать, выбрав в раскрывающемся списке, который содержит все возможные категории.

Пользователь создает следующие категории: C1, C2, C3.

Пользователь создает следующие проекты, категория ассоциации: [Р1, С1], [Р2, С2], [Р3, С3]

В дальнейшем, категория С2 был удален. Теперь, если пользователь пытается отредактировать категорию Project P2, есть несколько проблем: a. Чтобы заполнить выпадающий список, необходимо найти категории. Но удаленные категории не будут восстановлены. Следовательно, C2 не будет извлечен. (Если удаленные категории будут извлечены, то в раскрывающемся списке будут заполнены удаленные, непригодные для использования поля)

b. Если C2 также извлекается, существует риск того, что пользователь может снова назначить удаленную категорию C2 в P2.

Каков наилучший подход к дизайну?

Answer 1

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

Булевский «удаленный» флаг означает, что вы не сможете (не могли) редактировать старые данные без обновления категории, но это можно отложить до тех пор, пока старые данные не будут отредактированы.

Answer 2

Не разрешайте им удалять C2. Или, альтернативно, разрешите им удалить C2 по мере необходимости, но измените все категории C2 в системе на неопределенную категорию. Таким образом, они должны выбрать категорию при следующем редактировании проекта (и он по-прежнему действителен, так как он указывает на ранее созданную категорию «неопределенные»).

Answer 3

Вы столкнулись с проблемой referential integrity.

Вы не можете удалить категорию, если она по-прежнему ссылается на существующий проект. Однако вы можете добавить флаг IsDeleted и теперь разрешить назначать новые проекты для этой категории.

Answer 4

Я использовал поле «Устаревшее», которое не удаляет категорию из существования, просто скрывается из соответствующих экранов/выпадающих меню, но позволяет использовать данные для отчетов по историческим причинам.

Answer 5

В целом, для структурных элементов, подобных этому, если у вас нет серьезного недостатка в хранении данных, оставьте элемент неповрежденным с удаленным флагом, так что вещи, которые ссылаются на него до того, как он был удален, не будут повреждены. Альтернативно, impelement - пульсация-delete, которая удаляет все, что ссылается на нее.

Answer 6

Чтобы сохранить согласованность, вы не можете удалить C2, но вы можете добавить опцию отключения его вместо фактического удаления. Таким образом, новые проекты не присваиваются C2.

Answer 7

Я обработал это с помощью мягкого удаления, упомянутого другими. Затем, когда вы заполняете мой раскрывающийся список, я добавляю C2 в верхнюю часть раскрывающегося списка при изменении проекта, который назначен C2 (только для удаленных категорий). Таким образом, все может быть в C2 и может быть перемещено из C2, но ничего нового не может быть помещено в C2 (потому что, если он еще не в C2, его нет в выпадающем списке.)

Я помню, что код для этого не был особенно симпатичным, но не очень сложным. Сейчас у меня нет проекта, но я могу добавить более подробную информацию позже, если вы заинтересованы.