Общедоступная учетная запись WeChat «Back-end Advanced», ориентированная на совместное использование серверных технологий: Java, Golang, WEB-инфраструктура, распределенное промежуточное программное обеспечение, управление услугами и т. д.
Старый водитель научил тебя всем деньгам и довел до продвинутого уровня, я не успел объяснить и сесть в автобус!
Я обнаружил, что некоторые даты в базе данных фактически хранятся в виде строк? Поэтому я обсудил с несколькими друзьями, как сохранить дату базы данных. На самом деле, я всегда предлагал сохранять отметку времени непосредственно с числовым значением. Почему я предлагаю это?
Ниже я объясню вам из концепции часового пояса, почему сохранение временных меток с числовыми значениями — лучшее решение, и в то же время, чтобы поделиться ими, пусть больше партнеров по разработке обращают внимание на эти детали.
Я считаю, что часовые пояса знакомы многим людям, потому что земля круглая, и угол восхода солнца, видимый в разных уголках земли, разный, то есть отображение времени у всех разное.
Например:
В это время наше пекинское время в Восточном 8-м округе составляет 10:00, поэтому время в Восточном 1-м округе составляет 3:00, но их время эквивалентно:
"2019-06-20 10:00 +8:00" = "2019-06-20 3:00 +1:00"
Итак, для людей в разных часовых поясах отображаемое время отличается, так как же сохранить время в данных в это время?
Я предполагаю, что вы используете новый метод Date() для сохранения текущей даты, но, насколько я знаю, тип базы данных DateTime не имеет информации о часовом поясе.Если вы сохраните дату в формате DateTime в это время, время информация о зоне будет потеряна.Если ваш сервер изменит адрес, данные о дате, считанные из базы данных, будут неправильными!
Может быть, вы скажете, тогда я не потеряю информацию о часовом поясе, когда буду использовать тип timeStamp для ее сохранения? На самом деле не потерял, нет проблем. Но, насколько мне известно, timeStamp не может храниться более 2037 лет, и вы должны учитывать, что тип timeStamp для каждых данных может быть разным.
Что касается использования строк для хранения времени, то тем более не рекомендуется.Пока не проблема сравнить размер даты с часовым поясом.Приведу пример:
to_char(SYSDATE, 'yyyy-MM-dd') > START_TIME
Чтобы сравнить размер времени, мне нужно сделать это, а также преобразовать системное время в строку для сравнения, а при преобразовании в строку для сравнения база данных также преобразует его во время для сравнения, не так ли? подумайте такого рода Где условия запроса будут лучше?
Мы также знаем, что в новом API времени LocalDateTime в JDK8 доступны богатые методы преобразования часовых поясов, но даже если вы говорите, что разбираетесь в различных причудливых способах использования LocalDateTime, вам придется столкнуться со сложными преобразованиями.
Поэтому нам нужно "абсолютное время", чтобы помочь нам записать дату и сохранить время преобразования вниз. Это "абсолютное время" является меткой времени. Определение метки времени должно начинаться с эталонного времени, эталонного времени. равно "1970-1-1 00:00:00 +0:00", начиная с этого времени, выражается целым числом и считается в секундах, и это целое время продолжает увеличиваться с течением времени. Таким образом, мне нужно только одно значение для точного представления времени, и это значение является абсолютным значением, то есть независимо от того, где я нахожусь в любом уголке земли, временная метка, представляющая время, одинакова, генерируется. все одинаковы, и нет понятия часового пояса, поэтому при промежуточной передаче системного времени не требуется дополнительное преобразование.Только при отображении пользователю оно преобразуется в местное время в строковом формате.
И очень важный момент, что в существующих языках программирования предусмотрены методы для получения временных меток, что не слишком удобно для взаимодействия нашего проекта на разных языках! Так что здесь я настоятельно рекомендую, чтобы интерфейсные и внутренние взаимодействия о времени использовали временные метки для взаимодействия.
В это время некоторые одноклассники могут снова подойти к бару.Вы используете числовое значение для представления времени.Когда я проверял базу данных своим зрением и ртом,я вообще не знал время.Я не знаю думаю, что об этом нужно беспокоиться. Проверка базы данных - это не что иное, как проверка данных, которые вам нужны. Вы можете преобразовать временную метку во время в sql, например:
from_unixtime(1561053690000)
Если вы хотите продолжить и сказать, что я просто хочу видеть время в таблице базы данных, я думаю, если вы хотите это сделать, зачем вам внешний интерфейс, просто покажите внешний интерфейс базы данных напрямую.
Позвольте мне суммировать многие преимущества хранения временных меток в числовых значениях в базах данных:
- Не слишком удобно сравнивать дату в базе данных, задачи по математике, которые будет знать первоклассник начальной школы, да и успеваемость хорошая;
- Числовые значения не являются препятствием для любого системного взаимодействия;
- Числовое хранение на основе абсолютного времени, нет проблем с часовым поясом;
- В интерактивном процессе отказываются от ненужных преобразований, число ходит по всему миру, пользователю нужно его отобразить, а интерфейсу нужно только получить временную метку для отображения правильного местного времени;
- Решена проблема, вызванная различной реализацией времени в каждой базе данных.Например, функция времени Mysql отличается от функции времени Oracle.Если ваш текущий sql имеет функцию времени, очень вероятно, что произойдет ошибка, если вы измените базу данных.