Lược đồ cơ sở dữ liệu MySQL cho thời gian biểu xe lửa

7

Tôi quan tâm đến lược đồ cơ sở dữ liệu MySQL sẽ như thế nào đối với thời gian biểu của tàu.

Nói chung, điều này được trình bày ở định dạng bảng là kết quả cuối cùng.

Train No.    11111  22222  11111
Train Day    Mo-Fr  Sat    Sun
Station A  d 06.00  07.00  07.00
Station B  d 06.10         07.10
Station C  d 06.20  07.15   
Station D  a 06.30         07.40
Station D  d 06.35  07.25
Station E  d 06.45  07.45

Vì vậy, mỗi chuyến tàu có một số xe lửa, nhưng điều đó không phải là duy nhất vì số lượng sẽ được nhân đôi vào Thứ Hai-Thứ Sáu đến Thứ Bảy và Chủ Nhật. Sau đó, một chuyến tàu sẽ dừng tại một số nhà ga, nhưng không phải tất cả, và đôi khi nhà ga cần thời gian đến (a) và khởi hành (d), hoặc một hoặc khác.

Các trạm có thể được đặt theo khoảng cách của họ.

Cho đến nay tôi đang nghĩ rằng tôi cần các bảng cho:

Trạm (ID, tên, khoảng cách, dòng)
Tàu hỏa (ID, tàu không, Hoạt động trong ngày, chi tiết)
Chạy tàu (Train.ID, Station.ID, mảng / dep, thời gian, ghi chú)

Điều này đã đủ bình thường?

Có nên nói chuyến tàu 11111 cho Thứ Hai-Thứ Sáu chỉ là một mục nhập với rất nhiều kết hợp Hoạt động trong ngày, tức là 7 cột (M, T, W, Th, F, S, Su)?
Không phải nó cũng nên xử lý một chuyến tàu chạy mà chỉ nói một ngày và không lặp lại hàng tuần?

mysql database-design schema

— Vicsig
nguồn

Khi bạn lập mô hình dữ liệu, đừng nhìn vào định dạng đầu vào là gì - hãy hỏi những câu hỏi bạn muốn có thể hỏi về dữ liệu. Không biết bạn sẽ có loại câu hỏi nào, chúng tôi không thể tìm ra các truy vấn mà chúng tôi cần chạy theo cấu trúc dữ liệu và vì vậy đó có phải là một thiết kế tốt hay không.

— Joe

Ồ ... và tôi có thể muốn xem chương trình lịch gốc của Palm đã xử lý các sự kiện đơn lẻ và lặp lại như thế nào; nó dường như có thể xử lý bất cứ thứ gì bạn có thể ném vào nó theo lịch trình sự kiện; nhiều may mắn hơn mà tôi đã có với iCalWiki / vCalWiki / hCalWiki.

— Joe

Ví dụ đưa ra là đầu ra. Loại truy vấn tôi sẽ chạy sẽ là đầu ra: thời gian đào tạo tại trạm X, thời gian biểu cho tàu Y hoặc tất cả thời gian biểu của tàu (ví dụ đã cho). Tức là một hiệu ứng bộ lọc.

— Vicsig

7

Tôi mạnh mẽ sẽ xem xét lưu trữ rõ ràng tất cả các ngày một lịch trình cụ thể thực sự chạy trên. Điều này sẽ cho một cấu trúc trông giống như thế này:

nhập mô tả hình ảnh ở đây

Bằng cách đó, bạn sẽ dễ dàng trả lời các câu hỏi như "Tất cả các chuyến tàu đến ga X vào ngày 1 tháng 10 là gì?". Nó cũng sẽ tạo ra "những khoảng trống tạm thời" khi các đoàn tàu không chạy (ví dụ ngày Giáng sinh) có thể được xác định. Một chuyến tàu một lần giờ chỉ đơn giản là một chuyến chỉ có một mục trong SCHEDULE_DAYS.

Vì lịch trình có thể khác nhau vào cuối tuần đến các ngày trong tuần, tôi nghĩ tốt hơn là nên có các hàng riêng biệt cho mỗi ngày. Điều này cho phép liên kết các lịch trình khác nhau cho mỗi ngày trong tuần, nếu bạn cần phải làm điều này.

— Chris Saxon
nguồn

Điều gì nếu bạn muốn giới thiệu một khía cạnh của hướng? Bảng lịch trình cho biết tàu đến từ ga nào

— theTypan

1

Bạn có thể suy ra hướng từ thời gian đến / đi của các trạm trong lịch trình

— Chris Saxon

1

Bạn có thể xử lý một lần chạy bằng cách có các trường ngày cho lần chạy đầu tiên và chấm dứt (ngày đầu tiên nó không còn chạy nữa). Điều này cũng sẽ cho phép bạn xử lý các thay đổi lịch trình. Ngày chạy đầu tiên trở thành một phần của khóa chính. Bạn có thể muốn một khóa chính thay thế trên bảng này cho bảng mối quan hệ.

Tôi sẽ xem xét chia các ngày trong tuần thành bảy trường chỉ báo riêng biệt. Điều này cho phép bạn linh hoạt để xử lý lịch trình chỉ chạy một số ngày nhất định trong tuần. Mối quan hệ giữa nhà ga và nhà ga có thể được giảm xuống (thời gian tàu, ga, loại (đến / đi) trong ngày). Ghi chú có thể đi vào một mối quan hệ riêng tùy thuộc vào mật độ của chúng.

— BillThor
nguồn