При создании базы данных для корпоративных приложений полезно ли сохранять дату создания

Question

Я только начал заниматься профессиональным программированием, и мой менеджер склонен диктовать, что я сохраняю дату создания, изменения и удаления во всех таблицах базы данных, которые мы используем.Я хочу знать, имеет ли смысл сохранять эти поля для корпоративных приложений.Причина, по которой я это спрашиваю, состоит в том, что, поскольку во всех примерах, учебных пособиях, которые я когда-либо читал в сети, в книгах никогда не было таких полей, а также это увеличивает сложность, потому что каждый раз, когда мне приходится работать с сущностями, я должен убедиться, что использую сущности.DeleteDate == null

Спасибо за ваши предложения

Answer 1

Это может быть хорошо. Первое, что я рекомендую вам сделать, это узнать о взглядах. Представления - это просто хранимые запросы. Взгляды - ваш друг.

Например, вместо того, чтобы искать «Где удалено не равно нулю» в вашей базовой таблице, вы можете создать представление с именем viewActiveWh независимо и отфильтровать представление, чтобы оно получало данные только в том случае, если Delete не равно нулю. Помните, просмотров - ваш друг .

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

• Если вы пометите как удаленные и положитесь на представления, которые показывают только активные данные (помните, представления - это ваши друзья ), это работает хорошо.
• Некоторые данные (особенно внутренние объединенные данные могут отсутствовать), если их нет)

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

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

Если вы делаете все свои обновления в хранимых процедурах, этот вид ведения записей не так сложен.

Answer 2

обычно лучше хранить все, что вы можете, и тогда в будущем вы можете решить удалить определенные поля / записи, что возможно.если вы не сохраните его, когда он уйдет, он уйдет, и вы никогда не получите его обратно.если вы храните его, и в наши дни нет причин не хранить его, так как пространство почти ничего не стоит, у вас будут данные через 2 года, когда вам нужно будет получить какой-то аудиторский отчет, который ваш менеджер собирается запросить

Answer 3

Рано или поздно необходим какой-то одитинг. Софт-удаление иногда зависит от удобства дизайна, но часто это юридические требования, которые никогда не удаляются. Чем больше растет бизнес, тем выше вероятность того, что к ним будет предъявлен иск по той или иной причине. Сохранение записей в таблицах помогает, когда пора собирать юридическую документацию.

Определенный процент людей (~ 2%) будет рад воспользоваться вашими услугами некоторое время, затем они закроют (попытаться удалить) свою учетную запись и вызовут карту Visa / Master, чтобы заявить о мошенничестве. Вам нужно будет задокументировать их деятельность и представить ее кредитным людям, чтобы бороться с этим требованием; Быть в списке «плохих торговцев» с процессорами кредитных карт очень дорого.

Answer 4

Это зависит от бизнеса, к которому относится ваше решение. Однако это не должно вызывать у вас проблем. Просто добавьте эту функциональность в базовый класс, расширенный всеми вашими сущностями.