Mysql
 sql >> Cơ Sở Dữ Liệu >  >> RDS >> Mysql

Thiết kế cơ sở dữ liệu quy tắc giá cho hệ thống đặt phòng khách sạn

Tôi đã thực sự làm việc thiết kế và triển khai hệ thống Đặt phòng khách sạn và có thể đưa ra lời khuyên sau dựa trên kinh nghiệm của mình.

Tôi muốn giới thiệu tùy chọn thiết kế thứ hai của bạn, lưu trữ một bản ghi cho từng kết hợp Ngày / Khách sạn riêng lẻ. Lý do là mặc dù sẽ có những khoảng thời gian mà Giá của một khách sạn giống nhau trong nhiều ngày thì có nhiều khả năng hơn điều đó, tùy thuộc vào tình trạng sẵn có, giá phòng sẽ thay đổi theo thời gian và trở nên khác nhau (các khách sạn có xu hướng tăng giá phòng khi tình trạng phòng trống giảm xuống).

Ngoài ra, có những phần thông tin quan trọng khác sẽ cần được lưu trữ cụ thể cho một ngày nhất định:

  1. Bạn sẽ cần quản lý tình trạng phòng trống của khách sạn, tức là vào Ngày x y Còn phòng. Điều này gần như chắc chắn sẽ thay đổi theo ngày.
  2. Một số khách sạn có những khoảng thời gian ngừng hoạt động trong đó khách sạn không hoạt động trong thời gian ngắn (thường là những ngày cụ thể).
  3. Thời gian chờ - một số Khách sạn chỉ cho phép đặt phòng trước một số ngày nhất định, điều này có thể khác nhau giữa các ngày trong tuần và các ngày cuối tuần.
  4. Số đêm tối thiểu, một lần nữa dữ liệu được lưu trữ theo ngày riêng lẻ cho biết nếu bạn đến vào ngày này, bạn phải ở lại x số đêm (giả sử vào cuối tuần)

Ngoài ra, hãy xem xét một người đặt phòng lưu trú dài một tuần, truy vấn cơ sở dữ liệu để trả lại giá và tình trạng sẵn có cho mỗi ngày lưu trú đó ngắn gọn hơn rất nhiều nếu bạn có bản ghi giá cho mỗi Ngày. Bạn có thể chỉ cần thực hiện một truy vấn trong đó Ngày giá phòng là GIỮA Ngày đến và Ngày đi để trả về một tập dữ liệu với một bản ghi cho mỗi ngày lưu trú.

Tôi nhận ra rằng với cách tiếp cận này, bạn sẽ lưu trữ nhiều bản ghi hơn nhưng với các bảng được lập chỉ mục tốt, hiệu suất sẽ ổn và việc quản lý dữ liệu sẽ đơn giản hơn nhiều. Đánh giá nhận xét của bạn, bạn chỉ đang nói trong khu vực 18000 bản ghi, đó là một khối lượng khá nhỏ (hệ thống mà tôi đã làm việc có vài triệu bản và hoạt động tốt).

Để minh họa việc quản lý dữ liệu bổ sung nếu bạn KHÔNG NÊN lưu trữ một bản ghi mỗi ngày, hãy tưởng tượng rằng một Khách sạn có giá 100 USD và 20 phòng trống trong cả tháng 12:

Bạn sẽ bắt đầu với một bản ghi:

1-Dec to 31st Dec Rate 100 Availability 20

Sau đó, bạn bán một phòng vào ngày 10 tháng 12.

Logic kinh doanh của bạn bây giờ phải tạo ba bản ghi từ bản ghi ở trên:

1-Dec to 9th Dec Rate 100 Availability 20 10-Dec to 10th Dec Rate 100 Availability 19 11-Dec to 31st Dec Rate 100 Availability 20

Sau đó, tỷ lệ thay đổi vào ngày 3 và ngày 25 tháng 12 thành 110

Logic kinh doanh của bạn bây giờ phải chia nhỏ dữ liệu một lần nữa:

1-Dec to 2-Dec Rate 100 Availability 20 3-Dec to 3-Dec Rate 110 Availability 20 4-Dec to 9-Dec Rate 100 Availability 20 10-Dec to 10-Dec Rate 100 Availability 19 11-Dec to 24-Dec Rate 100 Availability 20 25-Dec to 25-Dec Rate 110 Availability 20 26-Dec to 31-Dec Rate 100 Availability 20

Đó là logic nghiệp vụ và chi phí cao hơn so với việc lưu trữ một bản ghi mỗi ngày.

Tôi có thể đảm bảo với bạn rằng vào thời điểm bạn hoàn thành, hệ thống của bạn sẽ kết thúc với một hàng mỗi ngày, vì vậy bạn cũng có thể thiết kế nó theo cách đó ngay từ đầu và nhận được lợi ích của việc quản lý dữ liệu dễ dàng hơn và truy vấn cơ sở dữ liệu nhanh hơn.



  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. Việc phân loại InnoDB có thực sự chậm?

  2. Xếp hạng MYSQL SELECT của người dùng (nhiều hơn x &ít hơn y)

  3. Nhập và chèn tệp sql.gz vào cơ sở dữ liệu bằng putty

  4. Express.js và mô hình MySQL + xác thực

  5. Làm cách nào để hiển thị thống kê truy vấn cơ sở dữ liệu trên trang Wordpress?