Đây có phải là một cách vô lý để cấu trúc một lược đồ DB, hay tôi hoàn toàn thiếu một cái gì đó?

Tôi đã thực hiện một chút công việc với các cơ sở dữ liệu quan hệ và nghĩ rằng tôi hiểu các khái niệm cơ bản của thiết kế lược đồ tốt khá tốt. Gần đây tôi được giao nhiệm vụ tiếp quản một dự án trong đó DB được thiết kế bởi một nhà tư vấn được trả lương cao. Xin vui lòng cho tôi biết nếu ruột của tôi - "WTF ??!?" - được bảo hành, hay anh chàng này là một thiên tài mà anh ta hoạt động ra khỏi vương quốc của tôi?

DB trong câu hỏi là một ứng dụng nội bộ được sử dụng để nhập yêu cầu từ nhân viên. Chỉ cần nhìn vào một phần nhỏ của nó, bạn có thông tin về người dùng và thông tin về yêu cầu được đưa ra. Tôi sẽ thiết kế như thế này:

Bảng người dùng:

UserID (primary Key, indexed, no dupes)
FirstName
LastName
Department

Bảng yêu cầu

RequestID (primary Key, indexed, no dupes)
<...> various data fields containing request details
UserID -- foreign key associated with User table

Đơn giản phải không?

Tư vấn đã thiết kế nó như thế này (với dữ liệu mẫu):

Người dùng

UserID  FirstName   LastName
234     John        Doe
516     Jane        Doe
123     Foo         Bar

Bộ phận

DepartmentID   Name
1              Sales
2              HR
3              IT

UserDepidorTable

UserDepartmentID   UserID   Department
1                  234      2
2                  516      2
3                  123      1

RequestTable

RequestID   UserID   <...>
1           516      blah
2           516      blah
3           234      blah

Toàn bộ cơ sở dữ liệu được xây dựng như thế này, với mỗi phần dữ liệu được gói gọn trong bảng riêng của nó, với ID số liên kết mọi thứ với nhau. Rõ ràng nhà tư vấn đã đọc về OLAP và muốn 'tốc độ tra cứu số nguyên'

Ông cũng có một số lượng lớn các thủ tục được lưu trữ để tham chiếu chéo tất cả các bảng này.

Đây có phải là thiết kế hợp lệ cho SQL DB cỡ nhỏ đến trung bình không?

Cảm ơn đã cho ý kiến ​​/ câu trả lời ...

Làm cho cảm giác hoàn hảo với tôi. Nó chỉ là rất bình thường, mà truyền tải rất nhiều tính linh hoạt mà bạn sẽ không có. Dữ liệu không chuẩn hóa là một cơn đau ở mông.

Tôi không nghĩ rằng một WTF được bảo hành hoặc anh chàng đó đang thực hiện bất kỳ kiểu thiết kế thiên tài điên rồ nào - đó là chuẩn hóa cơ sở dữ liệu khá chuẩn.

Lý do cho bảng bộ phận là nếu bạn không đặt các phòng ban vào một bảng riêng biệt, bạn sẽ phải giao dịch với người dùng trong các bộ phận "Bán hàng", "bán hàng", "Nhân viên bán hàng", "Bán hàng" và "Bán hàng", trừ khi bạn làm một cái gì đó để ngăn chặn nó. Và có thêm bảng là (một phần) cách tốt nhất tôi biết để làm điều đó.

Liệu có nên có một bảng UserDepidor là một cuộc gọi khó khăn hơn hay không, điều đó tất nhiên có nghĩa là không có quyết định nào là lối thoát và điên rồ. Một mặt, đó là một nỗi đau khi tất cả thiết kế bảng và logic của bạn đã đảm nhận một bộ phận cho mỗi người dùng và sau đó thay đổi, mặt khác thực hiện thêm một tham gia mà không có lý do trong nhiều năm và là một khả năng thực sự và cũng là một nỗi đau.

Cá nhân tôi đồng ý với bạn rằng bảng UserDepidor có lẽ là quá mức cần thiết. Ngay cả khi được bao gồm, nhiều khả năng mọi người sẽ viết các truy vấn giả định rằng chỉ có một người dùng cho mỗi bộ phận, do đó bạn sẽ kết thúc với điều tồi tệ nhất của cả hai thế giới - tham gia thêm mà không cần lý do trước khi cần bảng và mã không hoạt động dù sao một khi nhiều hơn một bộ phận cho mỗi người dùng được phép.

EDIT - Một yếu tố chính thúc đẩy việc có nên hỗ trợ nhiều mối quan hệ hay không là nếu các quy tắc kinh doanh rõ ràng. Nếu bạn không biết làm thế nào một người dùng trong nhiều phòng ban thậm chí sẽ làm việc thì sẽ không có nhiều điểm trong việc thêm bảng, vì mã của bạn không thể xử lý chính xác các trường hợp người dùng ở nhiều phòng ban.

Hãy tưởng tượng rằng bạn đã cho phép nhiều bộ phận trên mỗi người dùng, chỉ trong trường hợp. Sau đó, bạn đã thực hiện quy tắc kinh doanh để gán hoa hồng, dựa trên bộ phận. Sau đó, nhiều bộ phận đã được cho phép. May mắn thay, bạn cũng có tầm nhìn xa để viết mã hoa hồng của mình theo cách đã tính đến điều này. Thật không may, bạn đã thêm hoa hồng từ mỗi bộ phận cho người dùng ở cả hai. Quản lý muốn bạn dựa trên vai trò của mỗi người cho mỗi lần bán. Vì vậy, có bao nhiêu tốt đã có bảng trước? Còn những bảng khác mà bạn có "chỉ trong trường hợp" không bao giờ cần thiết thì sao?

LATER EDIT - Một lý do khác mà nhà tư vấn có thể muốn thêm tất cả các bảng trung gian được đề cập trong câu hỏi tiếp theo này , câu trả lời đưa ra một số lý do tại sao việc tái cấu trúc cơ sở dữ liệu thường khó hơn mã tái cấu trúc, điều này có xu hướng đẩy bạn về phía phương pháp "đặt trong tất cả các bảng bạn có thể cần".

Nếu yêu cầu là có nhiều bộ phận cho mỗi người dùng, thiết kế này có ý nghĩa. Nắm bắt duy nhất về nó là UserDepartmentTablecó một khóa thay thế UserDepartmentIDkhông cần thiết (chỉ cần tạo UserIdvà DepartmentIdmột khóa chính tổng hợp).

Nếu người dùng chỉ thuộc về một bộ phận duy nhất, thiết kế của bạn có ý nghĩa (mặc dù bảng tra cứu bộ phận vẫn sẽ là một điều tốt).

Một số yêu cầu không rõ ràng trong câu hỏi của bạn. Câu trả lời đúng phụ thuộc vào những gì khách hàng của bạn muốn - Nếu tôi là bạn, tôi sẽ hỏi khách hàng về điều này:

0-Sự khác biệt giữa người dùng và nhân viên là gì?

1-Giả sử một nhân viên = người dùng, nếu nhân viên thay đổi phòng ban thì sao?

2-Một nhóm nhân viên có thể đưa ra 1 yêu cầu không?

3-Một nhân viên có thể thuộc nhiều bộ phận không? CEO thì sao

4-Có tập hợp nhân viên nào được phép đưa ra yêu cầu không?

5-Điều gì xảy ra với yêu cầu khi hồ sơ nhân viên bị xóa (nếu có)?

6-Bạn có thể xóa một yêu cầu? Điều gì xảy ra khi yêu cầu bị hủy (đảm bảo bạn không xóa hồ sơ nhân viên bằng RI)

7-Nhân viên có thể thực hiện yêu cầu "giống nhau" nhiều lần không (xác định "giống")

8-Cách xử lý yêu cầu cho nhân viên khi họ rời công ty (hủy yêu cầu của họ hoặc xóa yêu cầu?)

Có thể có nhiều câu hỏi hơn, nhưng quan điểm của tôi là giải pháp phụ thuộc vào yêu cầu chính xác và phạm vi dự án. Khi đã được xác định, lược đồ có thể được dẫn xuất trực tiếp. Theo đó cả hai giải pháp được trình bày có thể đúng.

Tôi muốn thêm một vài ghi chú dạng điểm nói chuyện rõ ràng về một số lợi thế tiềm năng của việc sử dụng bảng tham gia theo cách mà nhà tư vấn được trả lương cao của bạn đã làm.

• Được lập chỉ mục chính xác (ví dụ: nếu UserDepidorTable lập chỉ mục hai khóa ngoại), chỉ có một sự mất hiệu suất nhỏ của bảng tham gia như thế này do các khóa ngoại không phải là duy nhất. Nếu các khóa ngoại được đảm bảo là duy nhất, theo lý thuyết cơ sở dữ liệu nhỏ mà tôi biết, việc tìm kiếm UserDepartmentTable.Departmentkhông "khó" hơn tìm kiếm bất kỳ cột nào khác trong Userbảng.
• Bảng tham gia cho phép bạn linh hoạt hơn để thiết lập thông tin khác về sự liên kết giữa người dùng và bộ phận (ví dụ: dấu thời gian khi tạo).
• Bảng tham gia cho phép bạn "phiên bản" liên kết khá dễ dàng (ví dụ: khi người dùng thay đổi các phòng ban, kích hoạt một số cờ boolean chỉ mục như UserDepartmentTable.Activesai và tạo một liên kết mới đang hoạt động). Cũng có thể có phiên bản liên kết bộ phận với mô hình hai bảng (chỉ Người dùng và Bộ), nhưng khó hơn và cần thêm ít nhất một cột hoặc thực hiện các thao tác nhào lộn cơ sở dữ liệu để tránh trùng lặp các khóa chính.
• Nó cho phép bạn chỉ định liên kết một-nhiều hoặc nhiều-một hoặc nhiều-nhiều-khá dễ dàng.

Điều đó đang được nói, có một số lý do KHÔNG làm những gì mà nhà tư vấn được trả lương cao của bạn đã làm.

• Tất cả những lợi ích trên đều là dự đoán về những nhu cầu có thể có trong tương lai, những điều quá phức tạp cho ngày nay. Nó không tuân thủ YAGNI. Sau này, việc viết một di chuyển chuyển từ mô hình hai bảng của bạn sang mô hình bảng tham gia là một khó khăn không đáng kể. Bạn có thể làm điều đó khi nhu cầu kinh doanh xuất hiện. Để làm điều đó trước đó có thể gây nhầm lẫn.
• Nó gây nhầm lẫn cho các nhà phát triển khác. Mặc dù, vâng, tôi muốn nói rằng kỳ vọng cho một nhà phát triển web có tầm vóc của bạn (nơi bạn đang xem xét các quyết định của chuyên gia tư vấn) sẽ hiểu và nhận ra một bảng tham gia, nó vẫn phức tạp hơn mức cần thiết và xem xét việc thiếu nhu cầu kinh doanh, nó gây nhầm lẫn.

Không có cấu trúc đầy đủ của thông tin cần thiết, tôi không thể nói nó có khủng khiếp hay không. Nhưng ít nhất phần được hiển thị không phải là thiết kế "WTF". Nó chỉ có vẻ như là dạng cấu trúc dữ liệu thông thường thứ 3 (vâng, về mặt lý thuyết chúng ta cũng có thứ 4 và thứ 5)

Một số cuộc thảo luận có thể có chỗ cho UserDepidorTable giữa hai trường khóa "tự nhiên" và "nhân tạo" trong phần hiển thị. Không có gì hơn, như tôi có thể thấy

Chuẩn hóa là quy tắc của nhà phát triển / nhà thiết kế DB giỏi vì nhiều lý do, * de * bình thường hóa đôi khi được sử dụng ở giữa các phát triển để giành chiến thắng tốc độ