Lý lịch

Tôi là sinh viên CS năm thứ nhất và tôi làm việc bán thời gian cho doanh nghiệp nhỏ của bố tôi. Tôi không có kinh nghiệm phát triển ứng dụng trong thế giới thực. Tôi đã viết các kịch bản bằng Python, một số khóa học bằng C, nhưng không có gì như thế này.

Cha tôi có một doanh nghiệp đào tạo nhỏ và hiện tại tất cả các lớp được lên lịch, ghi lại và theo dõi thông qua một ứng dụng web bên ngoài. Có một tính năng xuất / "báo cáo" nhưng nó rất chung chung và chúng tôi cần báo cáo cụ thể. Chúng tôi không có quyền truy cập vào cơ sở dữ liệu thực tế để chạy các truy vấn. Tôi đã được yêu cầu thiết lập một hệ thống báo cáo tùy chỉnh.

Ý tưởng của tôi là tạo các bản xuất và nhập CSV chung (có thể bằng Python) vào cơ sở dữ liệu MySQL được lưu trữ trong văn phòng mỗi đêm, từ đó tôi có thể chạy các truy vấn cụ thể cần thiết. Tôi không có kinh nghiệm về cơ sở dữ liệu nhưng hiểu những điều cơ bản. Tôi đã đọc một chút về việc tạo cơ sở dữ liệu và các hình thức bình thường.

Chúng tôi có thể bắt đầu có khách hàng quốc tế sớm, vì vậy tôi muốn cơ sở dữ liệu không phát nổ nếu / khi điều đó xảy ra. Chúng tôi hiện cũng có một vài tập đoàn lớn là khách hàng, với các bộ phận khác nhau (ví dụ: công ty mẹ ACME, bộ phận chăm sóc sức khỏe ACME, bộ phận chăm sóc cơ thể ACME)

Lược đồ tôi đã đưa ra là như sau:

1. Từ góc độ khách hàng:
   • Khách hàng là bàn chính
   • Khách hàng được liên kết với bộ phận họ làm việc cho
     • Các phòng ban có thể nằm rải rác trên một quốc gia: Nhân sự ở Luân Đôn, Tiếp thị ở Swansea, v.v.
     • Các phòng ban được liên kết với bộ phận của một công ty
   • Các bộ phận được liên kết với công ty mẹ
2. Từ quan điểm của lớp học:
   • Phiên là bàn chính
     • Một giáo viên được liên kết với mỗi phiên
     • Một trạng thái được đưa ra cho mỗi phiên. Ví dụ 0 - Đã hoàn thành, 1 - Đã hủy
     • Các phiên được nhóm thành "gói" có kích thước tùy ý
   • Mỗi gói được gán cho một khách hàng

Tôi "thiết kế" (giống như viết nguệch ngoạc) lược đồ trên một tờ giấy, cố gắng giữ nó bình thường hóa ở dạng thứ 3. Sau đó tôi đã cắm nó vào MySQL Workbench và nó làm cho tất cả đều đẹp đối với tôi:
( Bấm vào đây để xem đồ họa có kích thước đầy đủ )

_{(nguồn: maian.org )}

Các truy vấn mẫu tôi sẽ chạy

• Những khách hàng nào còn tín dụng vẫn không hoạt động (những khách hàng không có lớp dự kiến ​​trong tương lai)
• Tỷ lệ tham dự của mỗi khách hàng / bộ phận / bộ phận (được đo bằng id trạng thái trong mỗi phiên)
• Có bao nhiêu lớp có một giáo viên trong một tháng
• Cờ khách hàng có tỷ lệ tham dự thấp
• Báo cáo tùy chỉnh cho các phòng nhân sự với tỷ lệ tham dự của những người trong bộ phận của họ

Câu hỏi

• Đây có phải là quá áp đảo hay tôi đang đi đúng hướng?
• Có cần phải tham gia nhiều bảng cho hầu hết các truy vấn dẫn đến một hiệu suất lớn không?
• Tôi đã thêm một cột 'lastsession' cho khách hàng, vì nó có thể sẽ là một truy vấn phổ biến. Đây có phải là một ý tưởng tốt hay tôi nên giữ cho cơ sở dữ liệu được chuẩn hóa nghiêm ngặt?

cảm ơn vì đã dành thời gian cho tôi

Một số câu trả lời khác cho câu hỏi của bạn:

1) Lần đầu tiên bạn nhắm mục tiêu cho một người tiếp cận vấn đề như thế này. Tôi nghĩ rằng các gợi ý từ những người khác về câu hỏi này cho đến nay khá nhiều về nó. Làm tốt lắm!

2 & 3) Hiệu suất đạt được bạn sẽ thực hiện phần lớn phụ thuộc vào việc có và tối ưu hóa các chỉ mục phù hợp cho các truy vấn / thủ tục cụ thể của bạn và quan trọng hơn là khối lượng hồ sơ. Trừ khi bạn đang nói về hơn một triệu bản ghi trong các bảng chính của mình, bạn dường như đang đi đúng hướng để có một thiết kế chính thống, hiệu năng sẽ không phải là vấn đề trên phần cứng hợp lý.

Điều đó nói rằng, và điều này liên quan đến câu hỏi 3 của bạn, với sự khởi đầu bạn có lẽ bạn không nên thực sự lo lắng quá mức về hiệu suất hoặc siêu nhạy cảm với chính thống hóa bình thường ở đây. Đây là một máy chủ báo cáo bạn đang xây dựng, không phải là phụ trợ ứng dụng dựa trên giao dịch, sẽ có một hồ sơ khác nhiều về tầm quan trọng của hiệu suất hoặc chuẩn hóa. Một cơ sở dữ liệu sao lưu ứng dụng đăng ký và lên lịch trực tiếp phải chú ý đến các truy vấn mất vài giây để trả về dữ liệu. Chức năng máy chủ báo cáo không chỉ có dung sai hơn đối với các truy vấn phức tạp và dài, mà các chiến lược để cải thiện hiệu suất cũng khác nhau nhiều.

Ví dụ: trong môi trường ứng dụng dựa trên giao dịch, các tùy chọn cải thiện hiệu suất của bạn có thể bao gồm tái cấu trúc các thủ tục được lưu trữ và cấu trúc bảng của bạn ở mức thứ n hoặc phát triển chiến lược lưu trữ cho một lượng nhỏ dữ liệu thường được yêu cầu. Trong môi trường báo cáo, bạn chắc chắn có thể làm điều này nhưng bạn thậm chí có thể có tác động lớn hơn đến hiệu suất bằng cách giới thiệu cơ chế chụp nhanh trong đó quy trình được lên lịch chạy và lưu trữ các báo cáo được định cấu hình trước và người dùng của bạn truy cập dữ liệu ảnh chụp nhanh mà không bị căng thẳng trên tầng db của bạn một cơ sở theo yêu cầu.

Tất cả điều này là một lời ca ngợi dài dòng để minh họa rằng những nguyên tắc và thủ thuật thiết kế nào bạn sử dụng có thể khác nhau do vai trò của db bạn đang tạo. Tôi hy vọng điều đó hữu ích.

Bạn đã có ý tưởng đúng. Tuy nhiên, bạn có thể dọn sạch nó và xóa một số bảng ánh xạ (có *).

Những gì bạn có thể làm là trong bảng Các phòng ban, thêm CityId và DivisionId.

Ngoài ra, tôi nghĩ mọi thứ đều ổn ...

Những thay đổi duy nhất tôi sẽ thực hiện là:
1- Thay đổi VARCHAR của bạn thành NVARCHAR, nếu bạn có thể đi quốc tế, bạn có thể muốn unicode.

2- Thay đổi id id của bạn thành GUID (định danh duy nhất) nếu có thể (đây có thể chỉ là sở thích cá nhân của tôi). Giả sử cuối cùng bạn đến điểm mà bạn có nhiều môi trường (dev / test / staging / prod), bạn có thể muốn di chuyển dữ liệu từ cái này sang cái khác. Có Id GUID làm cho điều này dễ dàng hơn đáng kể.

3- Ba lớp cho Công ty của bạn -> Bộ phận -> Cấu trúc bộ phận có thể không đủ. Bây giờ, điều này có thể là quá kỹ thuật, nhưng bạn có thể khái quát hóa hệ thống phân cấp đó sao cho bạn có thể hỗ trợ n cấp độ sâu. Điều này sẽ làm cho một số truy vấn của bạn phức tạp hơn, do đó có thể không đáng để đánh đổi. Hơn nữa, có thể là bất kỳ máy khách nào có nhiều lớp hơn có thể dễ dàng "nhồi" vào mô hình này.

4- Bạn cũng có Trạng thái trong Bảng Máy khách là VARCHAR và không có liên kết đến bảng Trạng thái. Tôi mong đợi một chút rõ ràng hơn về những gì Trạng thái khách hàng thể hiện.

Không. Có vẻ như bạn đang thiết kế ở mức độ chi tiết tốt.

Tôi nghĩ rằng Quốc gia và Công ty thực sự là cùng một thực thể trong thiết kế của bạn, cũng như Thành phố và Bộ phận. Tôi sẽ thoát khỏi bảng Quốc gia và Thành phố (và Thành phố_Has_Depemony) và, nếu cần, hãy thêm cờ boolean IsPublicSector vào bảng Công ty (hoặc cột CompanyType nếu có nhiều lựa chọn hơn là Đơn vị tư nhân / Khu vực công).

Ngoài ra, tôi nghĩ rằng có một lỗi trong việc sử dụng bảng của bạn. Có vẻ như bảng Bộ phận đóng vai trò tham chiếu đến các loại phòng ban khác nhau mà mỗi bộ phận khách hàng có thể có. Nếu vậy, nó nên được gọi là DepartmentTypes. Nhưng khách hàng của bạn (người mà tôi cho là người tham dự) không thuộc về một LOẠI bộ phận, họ thuộc về một bộ phận thực tế trong một công ty. Hiện tại, bạn sẽ biết rằng một khách hàng nhất định thuộc về bộ phận nhân sự ở đâu đó, nhưng không phải là khách hàng nào!

Nói cách khác, Khách hàng nên được liên kết với bảng mà bạn gọi là Div Division_Has_Depemony (nhưng tôi sẽ gọi đơn giản là các Phòng ban). Nếu đúng như vậy, thì bạn phải thu gọn Thành phố thành các Bộ phận như đã thảo luận ở trên nếu bạn muốn sử dụng tính toàn vẹn tham chiếu tiêu chuẩn trong cơ sở dữ liệu.

Nhân tiện, đáng chú ý là nếu bạn đã tạo CSV và muốn tải chúng vào cơ sở dữ liệu myQuery, LOAD DATA LOCAL INFILE là người bạn tốt nhất của bạn: http://dev.mysql.com/doc/refman/5.1/ vi / tải dữ liệu.html . Mysqlimport cũng đáng để xem xét, và là một công cụ dòng lệnh về cơ bản là một trình bao bọc đẹp mắt xung quanh việc tải dữ liệu.

Hầu hết mọi thứ đã được nói, nhưng tôi cảm thấy rằng tôi có thể thêm một điều: điều khá phổ biến là các nhà phát triển trẻ lo lắng về hiệu suất hơi quá nhiều và câu hỏi của bạn về việc tham gia các bảng dường như đi theo hướng đó. Đây là một mô hình chống phát triển phần mềm có tên là ' Tối ưu hóa sớm '. Hãy cố gắng xua đuổi phản xạ đó khỏi tâm trí của bạn :)

Một điều nữa: Bạn có tin rằng bạn thực sự cần các bảng 'thành phố' và 'quốc gia' không? Sẽ không có cột 'thành phố' và 'quốc gia' trong bảng phòng ban đủ cho các trường hợp sử dụng của bạn? Ví dụ, ứng dụng của bạn cần liệt kê các phòng ban theo thành phố và thành phố theo quốc gia?

Sau các nhận xét dựa trên vai trò là Chuyên gia Báo cáo / Chuyên gia Báo cáo và quản lý chiến lược / hoạch định:

1. Tôi đồng ý với hướng dẫn của Larry ở trên. IMHO, Nó không quá nhiều thiết kế, một số thứ chỉ trông hơi lạc lõng. Để đơn giản, tôi sẽ gắn thẻ khách hàng trực tiếp vào ID công ty, Mô tả bộ phận, Mô tả bộ phận, ID loại bộ phận, ID loại bộ phận. Sử dụng ID loại bộ phận và ID loại bộ phận làm tài liệu tham khảo cho các bảng tra cứu và các trường phân tích / báo cáo nội bộ để thống nhất lâu dài.

2. Bảng gói chứa cột "Tín dụng", thực tế không nên được gắn với bảng cơ sở của Khách hàng để nếu chúng có nhiều gói bạn có thể thấy số tiền tín dụng còn lại cho các lớp trong tương lai là bao nhiêu? Ứng dụng có thể chăm sóc calc và lưu trữ tập trung trong bảng Client.

3. Thông tin công ty có thể sử dụng nhiều lĩnh vực hơn, bao gồm địa chỉ / điện thoại / vv rõ ràng. thông tin. Tôi cũng đã sẵn sàng để thêm vào các cột "DUNs" của D & B (Trang web / Chi nhánh / Cuối cùng), Dun và Bradstreet (D & B) có một danh mục lớn các công ty và sau này bạn sẽ thấy thông tin của họ rất hữu ích để báo cáo / phân tích. Điều này sẽ giải quyết vấn đề nhiều bộ phận mà bạn đề cập và cho phép bạn cuộn lên hệ thống phân cấp của chúng cho phụ / bộ phận / chi nhánh / v.v. của quân đoàn lớn.

4. Bạn không đề cập đến việc bạn sẽ làm việc với bao nhiêu hồ sơ có thể ngụ ý thiết lập cho mình một sáng kiến ​​phát triển lớn, có thể được thực hiện nhanh hơn và ít đau đầu hơn với phần mềm "báo cáo" được đóng gói sẵn. Nếu bạn không xử lý các hàng cơ sở dữ liệu lớn (<65000), hãy đảm bảo MS-Access, OpenOffice (Base) hoặc các giải pháp báo cáo / ứng dụng liên quan không thể thực hiện được. Bản thân tôi sử dụng phần mềm APEX miễn phí của Oracle khá nhiều, nó đi kèm với cơ sở dữ liệu miễn phí Oracle XE chỉ cần tải xuống từ trang web của họ.

5. FYI - Thông tin chi tiết báo cáo: đối với cơ sở dữ liệu lớn, bạn thường có hai trường hợp cơ sở dữ liệu a) cơ sở dữ liệu giao dịch để ghi lại từng bản ghi chi tiết. b) cơ sở dữ liệu báo cáo (data mart / kho dữ liệu) được đặt trên một máy riêng biệt. Để biết thêm thông tin tìm kiếm google cả Star Schema và Snowdrops Schema.

Trân trọng.

Tôi muốn chỉ giải quyết mối quan tâm rằng việc tham gia vào các bảng đột biến sẽ tạo ra một cú đánh hiệu suất. Đừng ngại bình thường hóa vì bạn sẽ phải tham gia. Tham gia là bình thường và được mong đợi trong các cơ sở dữ liệu quan hệ và chúng được thiết kế để xử lý chúng tốt. Bạn sẽ cần thiết lập các mối quan hệ PK / FK (đối với tính toàn vẹn dữ liệu, điều này rất quan trọng để xem xét khi thiết kế) nhưng trong nhiều cơ sở dữ liệu, FK không được lập chỉ mục tự động. Vì chúng sẽ được sử dụng trong các phép nối, bạn chắc chắn sẽ muốn bắt đầu bằng cách lập chỉ mục FKS. PK thường có được một chỉ số về sáng tạo vì chúng phải là duy nhất. Đúng là thiết kế nhà kho dữ liệu làm giảm số lượng tham gia, nhưng thường thì người ta không đến điểm lưu trữ dữ liệu cho đến khi có hàng triệu bản ghi cần truy cập trong một báo cáo. Thậm chí sau đó hầu như tất cả các kho dữ liệu đều bắt đầu với cơ sở dữ liệu giao dịch để thu thập dữ liệu theo thời gian thực và sau đó dữ liệu được chuyển đến kho theo lịch (hàng đêm hoặc hàng tháng hoặc bất cứ điều gì doanh nghiệp cần). Vì vậy, đây là một khởi đầu tốt ngay cả khi bạn cần thiết kế kho dữ liệu sau này để cải thiện hiệu suất báo cáo.

Tôi phải nói rằng thiết kế của bạn rất ấn tượng đối với một sinh viên CS năm đầu tiên.

Nó không quá kỹ thuật, đây là cách tôi sẽ tiếp cận vấn đề. Tham gia là tốt, sẽ không có nhiều thành tích (nó hoàn toàn cần thiết trừ khi bạn không chuẩn hóa cơ sở dữ liệu không được khuyến nghị!). Đối với các trạng thái, hãy xem liệu bạn có thể sử dụng kiểu dữ liệu enum thay thế để tối ưu hóa bảng đó không.

Tôi đã làm việc trong lĩnh vực đào tạo / trường học và tôi nghĩ rằng tôi chỉ ra rằng nói chung có mối quan hệ M: 1 giữa cái mà bạn gọi là "phiên" (ví dụ của một khóa học nhất định) và chính khóa học. Nói cách khác, danh mục của bạn cung cấp khóa học ("Tiếng Tây Ban Nha 101" hoặc bất cứ điều gì), nhưng bạn có thể có hai trường hợp khác nhau trong một học kỳ (Tu-Th được dạy bởi Smith, Wed-Fri do Jones dạy).

Ngoài ra, nó có vẻ như một khởi đầu tốt. Tôi cá là bạn sẽ thấy rằng miền khách hàng (biểu đồ dẫn đến "khách hàng") phức tạp hơn so với mô hình của bạn, nhưng đừng quá nhiệt tình với điều đó cho đến khi bạn có một số dữ liệu thực để hướng dẫn bạn.

Một vài điều xuất hiện trong tâm trí:

1. Các bảng dường như hướng đến báo cáo, nhưng không thực sự điều hành doanh nghiệp. Tôi sẽ nghĩ khi một khách hàng đăng ký, về cơ bản, một đơn hàng được đặt cho khách hàng tham dự một danh sách các phiên và đơn hàng đó có thể dành cho nhiều nhân viên trong một công ty. Có vẻ như một bảng "đặt hàng" sẽ thực sự nằm ở trung tâm hệ thống của bạn và thúc đẩy việc thu thập dữ liệu và báo cáo cuối cùng của bạn. (So ​​sánh các tài liệu giấy bạn đang sử dụng để điều hành doanh nghiệp với thiết kế cơ sở dữ liệu của bạn để xem liệu có phù hợp logic hay không.)

2. Các công ty thường không có sự phân chia. Nhân viên đôi khi thay đổi bộ phận / phòng ban, thậm chí có thể giữa phiên. Các công ty đôi khi thêm / xóa / đổi tên các bộ phận / phòng ban. Đảm bảo rằng nội dung thay đổi thời gian thực có thể có trong các bảng của bạn sẽ không gây khó khăn cho việc báo cáo / nhóm tiếp theo. Với rất nhiều dữ liệu liên hệ được chia thành nhiều bảng, bạn có thể phải thực thi xác thực nhập dữ liệu rất nghiêm ngặt để giữ cho báo cáo của bạn có ý nghĩa và bao quát. Ví dụ: khi một khách hàng mới được thêm vào, hãy đảm bảo rằng công ty / bộ phận / bộ phận / thành phố của anh ta khớp với các giá trị giống như đồng nghiệp của anh ta.

3. Khái niệm "gói" không rõ ràng chút nào.

4. Vì bạn chỉ ra rằng đó là một doanh nghiệp nhỏ, sẽ rất ngạc nhiên nếu hiệu suất sẽ là một vấn đề, xem xét tốc độ và công suất của các máy hiện tại.