MySQL: хорошо ли определять новый столбец даты, чтобы определить дату, когда была извлечена запись, если столбец create_at уже существует?

Question

Мне нужна помощь по управлению базой данных . Я пытаюсь получить данные из моей базы данных (фильтруя их по полю create_at ).

Не будет проблем при получении данных из моей базы данных, созданной на сегодняшнюю дату.

Например, сегодня равно 4/17 . Когда я запускаю функцию вставки сегодня, значение для создал_ также будет равно 4/17 . Поэтому, когда я захожу на свою веб-страницу и отображаю данные за 4/17, данные будут правильными.

Но скажем Я забыл получить данные за 4/15 , и мне нужно получить эти данные сегодня. Когда я сейчас вставлю эти данные в свою базу данных, create_at будет 4/17 , но смежные данные на самом деле для 4 / 15.

Теперь, когда я захожу на свою веб-страницу и отображаю данные за 4/15, я ничего не получу.

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

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

Вот скриншот моей текущей структуры таблицы:

Answer 1

Принятый ответ решает проблему XY . Вероятно, это не способ решить актуальную проблему.

Существует множество причин для помещения текущей даты-времени в базу данных (а не даты-времени, которая присуща таким данным, как встреча или дата рождения). Хотя это не следует использовать для целей аудита, это удобно для отладки и для работы с оптимистической блокировкой.

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

Если предположить, что то, что делается с записью, является частью транзакции ACID, то нужно рассмотреть два состояния - до и после. Ваш домен данных должен явно описать эти два состояния (использование значения даты, равного нулю / ненулевому, является просто неявным). Если транзакция не является атомарной, то, вероятно, будет больше состояний для рассмотрения.

В случае MySQL я бы реализовал это как тип данных enum (с ненулевым ограничением). Но в целом я стараюсь избегать ситуации, когда данные обновляются таким образом, используя синхронные операции, заключенные в транзакции.

Answer 2

Поскольку вы используете Laravel, вы можете просто переопределить значение created_at при создании модели. Так, например, вы можете сделать следующее:

$myModel->created_at = Carbon::parse('2019-04-15');
$myModel->save();

Это установит значение created_at на 15 апреля, а не сегодня. Следовательно, вам не нужен второй столбец date в вашей таблице.

UPDATE

Тем не менее, если вам нужна часть времени для отображения текущего времени, вы можете сделать следующее:

$myModel->created_at = Carbon::now()->setYear(2019)->setMonth(4)->setDay(15);
$myModel->save();