Столбцы SQL - Table Design - DateCreated и DateUpdated
Зависит от того, что вы делаете, но проще всего будет проверить вес вашей модели.
Вы можете сделать это (и сравнить с результатами предыдущей итерации), используя следующий код:
for parameter in model.parameters():
print(parameter.data)
Если веса меняются, нейронная сеть оптимизируется (что не ' t обязательно означает, что он узнает что-нибудь полезное, в частности).
5 ответов
Подход single-log-table-for-all-tables имеет две основных проблемы, о которых я могу думать:
- Дизайн таблицы журнала (вероятно), ограничит дизайн всех других таблиц. Скорее всего, таблица журнала имела бы один столбец под названием TableName и затем другой столбец под названием PKValue (который сохранит значение первичного ключа для записи, которую Вы регистрируете). Если некоторые Ваши таблицы имеют составные первичные ключи (т.е. больше чем один столбец), то дизайн Вашей таблицы журнала должен был бы составлять это (вероятно, при наличии столбцов как PKValue1, PKValue2 и т.д.).
- Если это будет каким-то веб-приложением, то пользовательские идентификационные данные, которые были бы доступны от триггера, будут учетной записью приложения вместо идентификатора пользователя веб-приложения (который наиболее вероятен, что Вы действительно хотите сохранить в своем поле CreatedBy). Это только помогло бы Вам различать записи, созданные Вашим кодом веб-приложения и записями, созданными иначе.
Столбцы CreatedDate и ModifiedDate не избыточны просто, потому что они определяются в каждой таблице. Я придерживался бы того подхода и поместил бы, вставляют, и обновление включает каждую таблицу для заполнения тех столбцов. Если бы я также должен был записать конечного пользователя, который внес изменение, то я пропустил бы триггеры и заполнил бы метку времени и пользовательские поля из моего кода приложения.
На проекте я работал над несколько лет назад, мы реализовали триггеры, которые обновили то, что мы назвали контрольной таблицей (это хранило основную информацию о внесенных изменениях, одна контрольная таблица на таблицу). Эта включенная измененная дата (и в последний раз измененный).
Они были только применены к ключевым таблицам (не соединения или таблицы справочных данных).
Это удалило много нормального разочарования необходимости составлять поля LastCreated & LastModified, но представило раздражение из-за совершенствования триггеров.
В конце дизайн таблицы триггера/аудита работал хорошо и все, что мы должны были помнить, должен был удалить и повторно применить триггеры перед ETL (!).
То, как часто необходимо будет включать, создало/обновило метки времени на уровне представления? Если ответ является чем-то большим чем "однажды в большом великом, в то время как", я думаю, что Вы были бы лучше обслужены при наличии тех столбцов в каждой таблице.
Я делаю последнего с таблицей "событий" или "журналом". По моему опыту, "обновленная" метка времени становится довольно быстрым срывом, потому что много времени, которое Вы находите сами в фиксации, где Вы хотите не только очень последнее время обновления.
Это для веб-CMS, я продолжаю работать. Создание и последнее обновление даты будут отображены на большинстве страниц и будут списки для созданного последнего (и обновлены) страницы. Администраторский интерфейс будет также использовать эту информацию.