MySQL 날짜/시간 유형을 사용하면 내 사랑이 바뀌지 않을 것입니다.

나는 그와 같은 팀에 있었기 때문에 그의 "mesophobic" 접근 방식에 매우 익숙하고 그의 많은 견해에 크게 동의하지만 한 가지 잘 이해되지 않는 것은 데이터베이스를 설계할 때, 나는 항상 날짜/시간 유형을 사용하지 않을 것입니다. 그가 한 일은 시간 관련 필드를 INT(10) 유형으로 설정한 다음 UNIX 타임스탬프를 사용하여 저장하는 것이었습니다. 저는 개인적으로 이 접근 방식에 크게 동의하지 않습니다.
우선, 유형 연산의 차이입니다. wiLdGoose의 접근 방식과 유사한 "시간 계산"은 본질적으로 정수 간의 연산입니다(그리고 이 정수는 길이가 매우 커서 10). 게다가 타임스탬프를 VARCHAR(10)으로 설정하면 자명한 효율성 문제가 발생합니다.
시간 계산, 정수 계산, 문자열 계산의 효율성에 대해 이 문서는 매우 예시적입니다.
둘째, 논리의 운용 문제가 있습니다. 이는 특히 높은 정밀도가 필요한 프로젝트에서 시간 유형을 사용할 때의 이점입니다. 예를 들어 "지난주의 데이터"가 필요하고 "데이터베이스가 생성된 이후 매주 월요일의 데이터를 가져오는 것"이 ​​필요한 경우, wiLdGoose 형제의 방법을 사용하면 이러한 작업의 복잡성을 상상할 수 있습니다.
마지막으로 직관성과 비직관성의 문제가 있습니다. 우리의 두뇌가 이 대규모 타임스탬프 시리즈를 날짜 형식으로 직접 변환하지 않는다는 것은 이해할 수 있습니다. 이에 비해 시간 유형을 직접 사용하는 것이 훨씬 더 직관적입니다(시간 형식 자체임).
현재 팀에서도 비슷한 방법을 사용하고 있습니다. 저도 비슷한 기술적 사항에 대해 오랫동안 논쟁을 벌여왔지만, 입장과 의사결정권의 문제로 아직까지 팀에서 제 의견을 수용하지 못하고 있는 것이 안타깝습니다.
MySQL은 단순하고 빠른 DBM으로 자리매김해 자연스럽게 빠르게 제어할 수 있지만, 한편으로는 더 이상 나아가지 않는 상황을 만들기도 쉽다. 이를 위해서는 각 항목의 데이터베이스 설계 세부 사항에 더 많은 관심을 기울여야 합니다. 새로운 기능을 지속적으로 추가하는 제품은 궁극적으로 응용 프로그램 지향적입니다.
마지막으로 공식 MySQL 시간 및 날짜 기능 매뉴얼이 첨부됩니다.

위 내용은 MySQL 날짜/시간 유형을 사용하여 Nothings Going my Love를 소개했으며, PHP 튜토리얼에 관심이 있는 친구들에게 도움이 되기를 바랍니다.