Có bao giờ ổn khi sử dụng danh sách trong cơ sở dữ liệu quan hệ?

Tôi đã cố gắng thiết kế một cơ sở dữ liệu để đi với một khái niệm dự án và gặp phải vấn đề có vẻ như là một vấn đề được tranh luận sôi nổi. Tôi đã đọc một vài bài viết và một số câu trả lời Stack Overflow nói rằng không bao giờ (hoặc gần như không bao giờ) được lưu trữ danh sách ID hoặc tương tự trong một trường - tất cả dữ liệu nên có liên quan, v.v.

Tuy nhiên, vấn đề tôi gặp phải là tôi đang cố gắng thực hiện một công việc được giao. Mọi người sẽ tạo các tác vụ, gán chúng cho nhiều người và nó sẽ lưu vào cơ sở dữ liệu.

Tất nhiên, nếu tôi lưu các tác vụ này riêng lẻ trong "Người", tôi sẽ phải có hàng chục cột "Nhiệm vụ" giả và quản lý vi mô vì có thể có từ 0 đến 100 nhiệm vụ được giao cho một người.

Sau đó, một lần nữa, nếu tôi lưu các tác vụ trong bảng "Nhiệm vụ", tôi sẽ phải có hàng chục cột "PersonID" giả và quản lý vi mô chúng - vấn đề tương tự như trước đây.

Đối với một vấn đề như thế này, liệu có thể lưu danh sách ID dưới dạng này hay dạng khác không hay tôi chỉ không nghĩ đến một cách khác mà điều này có thể đạt được mà không vi phạm các nguyên tắc?

Từ khóa và khái niệm chính bạn cần điều tra là chuẩn hóa cơ sở dữ liệu .

Những gì bạn sẽ làm, thay vì thêm thông tin về các bài tập vào bảng người hoặc nhiệm vụ, là bạn thêm một bảng mới với thông tin bài tập đó, với các mối quan hệ liên quan.

Ví dụ, bạn có các bảng sau:

Người:

+ + + +
| ID | Tên |
+ ==== + =========== +
| 1 | Alfred |
| 2 | Jebediah |
| 3 | Gia-cốp |
| 4 | Ezekiel |
+ + + +

Nhiệm vụ:

+ + + +
| ID | Tên |
+ ==== + ==================== +
| 1 | Nuôi gà |
| 2 | Cày |
| 3 | Bò sữa |
| 4 | Tăng chuồng trại |
+ + + +

Sau đó, bạn sẽ tạo một bảng thứ ba với Bài tập. Bảng này sẽ mô hình hóa mối quan hệ giữa mọi người và các nhiệm vụ:

+ + + + + +
| ID | Cá nhân | Nhiệm vụ |
+ ==== + =========== + ========= +
| 1 | 1 | 3 |
| 2 | 3 | 2 |
| 3 | 2 | 1 |
| 4 | 1 | 4 |
+ + + + + +

Sau đó, chúng tôi sẽ có một ràng buộc Khóa ngoài, sao cho cơ sở dữ liệu sẽ thực thi rằng PersonId và TaskIds phải là ID hợp lệ cho các mục nước ngoài đó. Đối với hàng đầu tiên, chúng ta có thể thấy PersonId is 1, vì vậy Alfred , được chỉ định cho TaskId 3, vắt sữa bò .

Những gì bạn có thể thấy ở đây là bạn có thể có ít hoặc nhiều nhiệm vụ cho mỗi nhiệm vụ hoặc mỗi người tùy thích. Trong ví dụ này, Ezekiel không được giao bất kỳ nhiệm vụ nào và Alfred được chỉ định 2. Nếu bạn có một nhiệm vụ với 100 người, thực hiện SELECT PersonId from Assignments WHERE TaskId=<whatever>;sẽ mang lại 100 hàng, với nhiều Người khác nhau được chỉ định. Bạn có thể WHEREtrên PersonId để tìm tất cả các nhiệm vụ được giao cho người đó.

Nếu bạn muốn trả về các truy vấn thay thế Id bằng Tên và tác vụ, thì bạn có thể tìm hiểu cách THAM GIA bảng.

Bạn đang hỏi hai câu hỏi ở đây.

Đầu tiên, bạn hỏi liệu có ổn không khi lưu danh sách được xê-ri hóa trong một cột. Vâng, nó ổn Nếu dự án của bạn gọi cho nó. Một ví dụ có thể là thành phần sản phẩm cho một trang danh mục, nơi bạn không muốn thử theo dõi từng thành phần riêng lẻ.

Thật không may, câu hỏi thứ hai của bạn mô tả một kịch bản mà bạn nên chọn cách tiếp cận quan hệ hơn. Bạn sẽ cần 3 bàn. Một cho mọi người, một cho các nhiệm vụ và một cho duy trì danh sách các nhiệm vụ được giao cho những người nào. Cái cuối cùng đó sẽ là hàng dọc, một hàng cho mỗi người / kết hợp tác vụ, với các cột cho khóa chính, id tác vụ và id người.

Những gì bạn đang mô tả được gọi là mối quan hệ "nhiều đến nhiều", trong trường hợp của bạn giữa Personvà Task. Nó thường được thực hiện bằng cách sử dụng bảng thứ ba, đôi khi được gọi là bảng "liên kết" hoặc "tham chiếu chéo". Ví dụ:

create table person (
    person_id integer primary key,
    ...
);

create table task (
    task_id integer primary key,
    ...
);

create table person_task_xref (
    person_id integer not null,
    task_id integer not null,
    primary key (person_id, task_id),
    foreign key (person_id) references person (person_id),
    foreign key (task_id) references task (task_id)
);

... không bao giờ (hoặc gần như không bao giờ) được lưu trữ danh sách ID hoặc tương tự trong một trường

Lần duy nhất bạn có thể lưu trữ nhiều hơn một mục dữ liệu trong một trường là khi trường đó chỉ được sử dụng như một thực thể duy nhất và không bao giờ được coi là được tạo thành từ các phần tử nhỏ hơn đó. Một ví dụ có thể là một hình ảnh, được lưu trữ trong trường BLOB. Nó được tạo thành từ rất nhiều phần tử nhỏ hơn (byte) nhưng những phần tử này không có ý nghĩa gì đối với cơ sở dữ liệu và chỉ có thể được sử dụng cùng nhau (và trông khá đẹp đối với Người dùng cuối).

Vì "danh sách", theo định nghĩa, được tạo thành từ các yếu tố (vật phẩm) nhỏ hơn, nên đây không phải là trường hợp ở đây và bạn nên bình thường hóa dữ liệu.

... Nếu tôi lưu riêng các tác vụ này trong "Người", tôi sẽ phải có hàng tá cột "Nhiệm vụ" giả ...

Không. Bạn sẽ có một vài hàng trong Bảng giao nhau (còn gọi là Thực thể yếu) giữa Người và Nhiệm vụ. Cơ sở dữ liệu thực sự tốt khi làm việc với nhiều hàng; họ thực sự khá rác khi làm việc với nhiều cột [lặp đi lặp lại].

Ví dụ rõ ràng đẹp được đưa ra bởi whatsisname.

Nó có thể là hợp pháp trong các lĩnh vực được tính toán trước.

Nếu một số truy vấn của bạn đắt tiền và bạn quyết định sử dụng các trường được tính toán trước được cập nhật tự động bằng cách sử dụng trình kích hoạt cơ sở dữ liệu, thì việc giữ các danh sách bên trong một cột là hợp pháp.

Ví dụ: trong Giao diện người dùng bạn muốn hiển thị danh sách này bằng chế độ xem lưới, trong đó mỗi hàng có thể mở chi tiết đầy đủ (với danh sách đầy đủ) sau khi nhấp đúp:

REGISTERED USER LIST
+------------------+----------------------------------------------------+
|Name              |Top 3 most visited tags                             |
+==================+====================================================+
|Peter             |Design, Fitness, Gifts                              |
+------------------+----------------------------------------------------+
|Lucy              |Fashion, Gifts, Lifestyle                           |
+------------------+----------------------------------------------------+

Bạn đang giữ cột thứ hai được cập nhật bằng trình kích hoạt khi khách hàng truy cập bài viết mới hoặc theo tác vụ theo lịch trình.

Bạn có thể làm cho một trường như vậy có sẵn ngay cả để tìm kiếm (như văn bản bình thường).

Đối với những trường hợp như vậy, việc giữ danh sách là hợp pháp. Bạn chỉ cần xem xét trường hợp có thể vượt quá độ dài trường tối đa.

Ngoài ra, nếu bạn đang sử dụng Microsoft Access, các trường đa trị được cung cấp là một trường hợp sử dụng đặc biệt khác. Họ tự động xử lý danh sách của bạn trong một lĩnh vực.

Nhưng bạn luôn có thể quay trở lại dạng chuẩn hóa được hiển thị trong các câu trả lời khác.

Tóm tắt: Các dạng cơ sở dữ liệu thông thường là mô hình lý thuyết cần thiết để hiểu các khía cạnh quan trọng của mô hình hóa dữ liệu. Nhưng tất nhiên bình thường hóa không tính đến hiệu suất hoặc chi phí khác để lấy dữ liệu. Nó nằm ngoài phạm vi của mô hình lý thuyết đó. Nhưng việc lưu trữ danh sách hoặc các bản sao được tính toán trước (và được kiểm soát) khác thường được yêu cầu khi triển khai thực tế.

Theo cách hiểu trên, trong triển khai thực tế, chúng ta sẽ thích truy vấn dựa trên hình thức bình thường hoàn hảo và chạy 20 giây hoặc truy vấn tương đương dựa trên các giá trị được tính toán trước mất 0,08 giây? Không ai thích sản phẩm phần mềm của họ bị buộc tội chậm.

Cho hai bảng; chúng ta sẽ gọi họ là Người và Nhiệm vụ, mỗi người có ID riêng (PersonID, TaskID) ... ý tưởng cơ bản là tạo một bảng thứ ba để liên kết chúng lại với nhau. Chúng tôi sẽ gọi bảng này PersonToTask. Tối thiểu nó phải có ID riêng, cũng như hai cái khác Vì vậy, khi nói đến việc giao ai đó cho một nhiệm vụ; bạn sẽ không còn cần phải CẬP NHẬT bảng Person, bạn chỉ cần XÁC NHẬN một dòng mới vào PersonToTaskTable. Và việc bảo trì trở nên dễ dàng hơn - cần xóa một tác vụ chỉ trở thành XÓA dựa trên TaskID, không cần cập nhật bảng Person và phân tích cú pháp liên quan

CREATE TABLE dbo.PersonToTask (
    pttID INT IDENTITY(1,1) NOT NULL,
    PersonID INT NULL,
    TaskID   INT NULL
)

CREATE PROCEDURE dbo.Task_Assigned (@PersonID INT, @TaskID INT)
AS
BEGIN
    INSERT PersonToTask (PersonID, TaskID)
    VALUES (@PersonID, @TaskID)
END

CREATE PROCEDURE dbo.Task_Deleted (@TaskID INT)
AS
BEGIN
    DELETE PersonToTask  WHERE TaskID = @TaskID
    DELETE Task          WHERE TaskID = @TaskID
END

Làm thế nào về một báo cáo đơn giản hoặc tất cả những người được giao cho một nhiệm vụ?

CREATE PROCEDURE dbo.Task_CurrentAssigned (@TaskID INT)
AS
BEGIN
    SELECT PersonName
    FROM   dbo.Person
    WHERE  PersonID IN (SELECT PersonID FROM dbo.PersonToTask WHERE TaskID = @TaskID)
END

Bạn tất nhiên có thể làm nhiều hơn nữa; Thời gian dịch chuyển có thể được thực hiện nếu bạn đã thêm các trường DateTime cho TaskAssiated và TaskCompleted. Tuỳ bạn

Nó có thể hoạt động nếu bạn nói rằng bạn có các khóa Chính có thể đọc được của con người và muốn có một danh sách các tác vụ # mà không phải xử lý tính chất dọc của cấu trúc bảng. tức là dễ dàng hơn nhiều để đọc bảng đầu tiên.

------------------------  
Employee Name | Task 
Jack          |  1,2,5
Jill          |  4,6,7
------------------------

------------------------  
Employee Name | Task 
Jack          |  1
Jack          |  2
Jack          |  5
Jill          |  4
Jill          |  6
Jill          |  7
------------------------

Câu hỏi sau đó sẽ là: danh sách nhiệm vụ nên được lưu trữ hoặc tạo theo yêu cầu, phần lớn sẽ phụ thuộc vào các yêu cầu như: mức độ thường xuyên của danh sách, mức độ chính xác có bao nhiêu hàng dữ liệu, cách sử dụng dữ liệu, v.v. .. sau đó phân tích sự đánh đổi để trải nghiệm người dùng và đáp ứng các yêu cầu nên được thực hiện.

Ví dụ: so sánh thời gian cần thiết để gọi lại 2 hàng so với chạy truy vấn sẽ tạo 2 hàng. Nếu mất nhiều thời gian và người dùng không cần danh sách cập nhật nhất (* mong đợi ít hơn 1 thay đổi mỗi ngày) thì có thể được lưu trữ.

Hoặc nếu người dùng cần một bản ghi lịch sử của các nhiệm vụ được giao cho họ, nó cũng sẽ có ý nghĩa nếu danh sách được lưu trữ. Vì vậy, nó thực sự phụ thuộc vào những gì bạn đang làm, không bao giờ nói không bao giờ.

Bạn đang lấy thứ nên là một cái bàn khác, xoay nó 90 độ và xỏ nó vào một cái bàn khác.

Giống như có một bảng đơn hàng nơi bạn có itemProdcode1, itemQuantity1, itemprice1 ... itemProdcode37, itemQuantity37, itemprice37. Ngoài việc lúng túng để xử lý theo chương trình, bạn có thể đảm bảo rằng ngày mai sẽ có người muốn đặt hàng 38 thứ.

Tôi chỉ làm theo cách của bạn nếu 'danh sách' không thực sự là một danh sách, tức là nơi nó đứng toàn bộ và mỗi chi tiết đơn hàng riêng lẻ không đề cập đến một thực thể độc lập và rõ ràng nào. Trong trường hợp đó, chỉ cần nhét tất cả vào một số loại dữ liệu đủ lớn.

Vì vậy, một đơn đặt hàng là một danh sách, Bill Of Vật liệu là một danh sách (hoặc một danh sách các danh sách, sẽ còn là một cơn ác mộng khi thực hiện "đi ngang"). Nhưng một ghi chú / bình luận và một bài thơ thì không.

Nếu nó "không ổn" thì thật tệ khi mọi trang Wordpress từng có một danh sách trong wp_usermeta với wp_capabilities trong một hàng, danh sách bị loại bỏ trong một hàng và các trang khác ...

Trong thực tế trong những trường hợp như thế này có thể tốt hơn cho tốc độ vì bạn hầu như sẽ luôn muốn có danh sách . Nhưng Wordpress không được biết đến là ví dụ hoàn hảo cho các thực tiễn tốt nhất.