Ngày-giờ là một giá trị
Giá trị ngày-giờ hầu như luôn được theo dõi trong phần mềm dưới dạng các giá trị đơn lẻ. Về mặt kỹ thuật, chúng được biểu thị bên trong dưới dạng số giây / mili giây / micro giây / nano giây kể từ kỷ nguyên .
Bạn có thể muốn hiển thị ngày và giờ một cách riêng biệt trong giao diện người dùng, nhưng không hiển thị trong nội bộ.
Ngoài ra, bạn gần như chắc chắn nên nghĩ về múi giờ. Các lập trình viên ngây thơ thường nghĩ rằng họ có thể bỏ qua múi giờ, nhưng điều đó gần như chắc chắn sẽ gây ra sự đau khổ sau này.
Hiểu cách xử lý ngày-giờ trong cơ sở dữ liệu của bạn
Các cơ sở dữ liệu khác nhau xử lý ngày-giờ khác nhau. Điều quan trọng tuyệt đối là bạn phải đọc tài liệu, chơi xung quanh, thử nghiệm và tìm hiểu chính xác cách cơ sở dữ liệu của bạn hoạt động.
Postgres có khả năng xử lý ngày giờ tuyệt vời và hợp lý. Ngay cả khi bạn sử dụng cơ sở dữ liệu khác, hãy tham khảo tài liệu Postgres tuyệt vời về date- các loại dữ liệu thời gian và các hàm ngày-giờ (lệnh) để tìm hiểu về các vấn đề khác nhau và về những gì được xác định bởi tiêu chuẩn SQL so với đặc biệt đối với cơ sở dữ liệu của bạn.
Lưu trữ trên toàn cầu, có mặt tại địa phương
Ngày-giờ là một vấn đề phức tạp và trơn tru một cách đáng ngạc nhiên. Một chìa khóa để giải quyết vấn đề đang hoạt động trong UTC . Lưu trữ các giá trị ngày-giờ của bạn trong cơ sở dữ liệu (hoặc trong các tệp được tuần tự hóa hoặc thông tin liên lạc XML / JSON) trong UTC. Viết hầu hết logic kinh doanh của bạn bằng UTC, ngoại trừ trường hợp múi giờ địa phương quan trọng, chẳng hạn như xác định "khởi đầu một ngày mới".
Khi bạn trình bày với người dùng, hãy sử dụng định dạng ISO 8601 hoặc bản địa hóa theo múi giờ của riêng họ (hoặc múi giờ mà họ mong đợi). Điều này tuân theo ý tưởng cơ bản của quốc tế hóa / bản địa hóa. Đối với các giá trị văn bản, bạn sử dụng các chuỗi khóa nhất định trong mã của mình. Khi trình bày trong giao diện người dùng, bạn ánh xạ các chuỗi nội bộ đó thành các giá trị văn bản được bản địa hóa (đã dịch) cho giao diện người dùng. Một số có ngày-giờ:UTC nội bộ, múi giờ địa phương trong giao diện người dùng.
Một lưu ý:Bạn có thể muốn cũng lưu trữ ngày-giờ địa phương vì lợi ích của lịch sử. Các quy tắc về múi giờ thay đổi thường xuyên và thất thường do các chính trị gia và quan chức. Cơ sở dữ liệu múi giờ của phần mềm của bạn có thể đã lỗi thời. Vì vậy, bạn có thể muốn lưu trữ những gì bạn hoặc người dùng tin là một ngày-giờ nhất định sau đó . Nhưng đừng dựa vào nó; xác định và lưu trữ giá trị UTC.
Mẹo:Học cách suy nghĩ và đọc trong thời gian 24 giờ. Cuộc sống của bạn với tư cách là một lập trình viên / trình gỡ lỗi / sysadmin sẽ trở nên dễ dàng hơn và ít bị lỗi hơn nhiều.
Joda-Time hoặc java.time
Các lớp java.util.Date và .Calendar đi kèm với Java nổi tiếng là rắc rối. Tránh chúng.
Thay vào đó, hãy sử dụng Joda-Time hoặc gói java.time mới được tích hợp vào Java 8 (lấy cảm hứng từ Joda-Time, được định nghĩa bởi JSR 310).
Cả hai thư viện đều sử dụng định dạng ISO 8601 làm định dạng mặc định cho cả việc phân tích cú pháp và tạo chuỗi.
ISO 8601
ISO 8601 là một tiêu chuẩn hợp lý xác định cách trình bày các giá trị ngày-giờ, múi giờ và hiệu số, thời lượng và khoảng thời gian ở các định dạng văn bản cụ thể và không mơ hồ. Nghiên cứu trang Wikipedia được viết tốt đó.
Đặc biệt lưu ý những gì gọi tiêu chuẩn Thời lượng
. Khoảng thời gian được xác định theo định dạng sau:PnYnMnDTnHnMnS ở đâu P có nghĩa là "Kỳ", T tách phần ngày khỏi phần thời gian và các phần tùy chọn khác là chữ số + chữ cái. Cuộc hẹn nửa giờ sẽ là PT30M . Điều này có thể hữu ích cho bạn, chẳng hạn như trường "period_" được thấy trong ERD
phía dưới. Trong Joda-Time, lớp Giai đoạn biểu thị một khoảng thời gian bằng cách theo dõi tháng, ngày, giờ, v.v. của nó và biết cách phân tích cú pháp và tạo chuỗi ở định dạng này.
Nửa công khai
Bạn có thể chọn lưu trữ các cuộc hẹn theo một trong hai cách. Một cách là ngày-giờ bắt đầu và thời lượng (90 phút, 20 phút, v.v.). Một cách khác là ghi lại cả ngày giờ bắt đầu và ngày dừng. Trong trường hợp này, cách tiếp cận thông thường và thường tốt nhất được gọi là "Half-Open". Điều này có nghĩa là bắt đầu là bao gồm trong khi phần kết là độc quyền .
Ví dụ:một cuộc hẹn kéo dài một giờ vào giờ sẽ chạy từ 11 giờ đến 12 giờ, nghĩa là "bắt đầu lúc 11 giờ sáng và chạy đến, nhưng không bao gồm, thời điểm đầu tiên của giờ tiếp theo (buổi trưa)". Cuộc hẹn tiếp theo sẽ bắt đầu từ 12:00 đến 13:00.
Tìm kiếm StackOverflow cho "Nửa công khai" để tìm thêm thảo luận cũng như các ví dụ và sơ đồ.
Nhiều-Nhiều
Mối quan hệ giữa Bệnh nhân và Bác sĩ là cái chúng tôi gọi là Many-To-Many . Một bác sĩ khám cho nhiều bệnh nhân và một bệnh nhân có thể gặp nhiều bác sĩ. Hãy chắc chắn rằng bạn biết về nhiều bảng trong thiết kế cơ sở dữ liệu quan hệ. Giải pháp luôn là thêm một bảng thứ ba, đôi khi được gọi là bảng "cầu nối" đóng vai trò là bảng con cho cả hai bảng cha khác. Trong trường hợp của bạn, Cuộc hẹn bảng là bảng cầu nối.
Bạn sẽ cần biết cách thực hiện các phép nối qua mối quan hệ nhiều-nhiều.
SQL trực tiếp
Nếu bạn chưa quen với lập trình hoặc mới sử dụng cơ sở dữ liệu quan hệ, tôi khuyên bạn nên tránh Hibernate. Bạn thực sự nên nắm bắt được những gì đang xảy ra. Hibernate có một số cách sử dụng thích hợp. Nhưng nếu bạn nghĩ rằng Hibernate sẽ khiến các vấn đề về cơ sở dữ liệu biến mất một cách kỳ diệu, bạn sẽ thất vọng.
Các thuộc tính
Thuộc tính tùy thuộc vào bạn. Chúng phụ thuộc vào vấn đề kinh doanh (hoặc bài tập về nhà?) Mà bạn đang cố gắng giải quyết. Bạn có những điều cơ bản đúng.
Lập lịch hẹn là một bài toán kinh doanh rất khó mà viết phần mềm. Ví dụ, bạn chỉ đơn giản là ghi lại các cuộc hẹn đang được thực hiện? Hay bạn đang theo dõi tình trạng sẵn có của các bác sĩ bằng cách tạo các khoảng thời gian được xác định trước và nếu có thì làm cách nào để xử lý các trường hợp ngoại lệ và thay đổi đối với lịch của từng bác sĩ? Bạn cần viết các yêu cầu và trường hợp sử dụng rất cụ thể. Rất dễ dàng để kỳ vọng của người dùng vượt quá yêu cầu của bạn.
Đây là một cái nhìn đơn giản.
