Khi nào sử dụng các bảng cơ sở dữ liệu SQL riêng biệt cho hai loại thông tin hơi khác nhau?

Question

Tôi cần trợ giúp về một quyết định SQL đã làm tôi bối rối một thời gian.

Tôi đang cố gắng tạo một trang web truyện ngắn nơi người dùng có thể viết câu chuyện của riêng họ và có thể duyệt qua những câu chuyện của họ, v.v. Tôi cũng có một bộ sưu tập các truyện ngắn cổ điển được viết bởi các nhà văn vĩ đại trong quá khứ. Tôi đang bối rối về việc liệu tôi có nên lưu trữ cả hai loại câu chuyện trong cùng một bảng cơ sở dữ liệu.

Tôi muốn giữ hai loại câu chuyện (tác giả/người dùng cổ điển) khác nhau ở một mức độ nào đó, vì bạn có thể tìm kiếm trang web và lọc ra các câu chuyện của người dùng từ kết quả. Nhưng tôi không thể chỉ có một hàng cơ sở dữ liệu trong bảng để biểu diễn điều này, tức là một CLASSIC boolean, vì với các cửa hàng ngắn cổ điển, một số hàng khác cũng sẽ khác nhau - không có người dùng, ngày sẽ là YYYY (tức là, 1869) thay vì một datetime đầy đủ khi người dùng gửi nó.

Tuy nhiên, tôi hoàn toàn không thể biện minh cho việc đặt chúng trong các bảng riêng biệt. Khi hầu hết các thuộc tính đều giống nhau, tôi có thực sự có hai bảng cơ sở dữ liệu khác nhau cho truyện ngắn không? Tại thời điểm này tôi điền vào NULL vào hàng người dùng cho truyện ngắn cổ điển, và tìm kiếm được lọc của tôi có một tùy chọn để tìm kiếm chỉ thông qua kinh điển, mà chọn từ cơ sở dữ liệu mà người dùng là NULL. Điều này dường như đạt hiệu suất mặc dù, khi bạn đang tìm kiếm thông qua một cơ sở dữ liệu khổng lồ của hàng triệu câu chuyện người dùng tiềm năng chỉ để tìm một vài nghìn câu chuyện cổ điển.

Lưu ý rằng cũng có các bảng khác, như thẻ cho các câu chuyện, được liên kết với bảng truyện ngắn.

Vì vậy, về cơ bản tôi hỏi bạn các chuyên gia SQL - liệu có đủ biện minh cho việc tách hai loại thông tin thành các bảng khác nhau không? Tôi hiện đang sử dụng SQLite trong phát triển nhưng sẽ chuyển sang MySQL hoặc PostgreSQL sau.

Answer 1

tôi có lẽ muốn đi với một cấu trúc bảng "cha-con", nơi bạn có phù hợp với từ khóa chính trên bảng, một cái gì đó như:

Stories: StoryId (PK), StoryType (U or C), StoryText, etc. (all of the shared stuff) 
UserStories: StoryId (PK and FK), UserId, etc. 
ClassicStories: StoryId (PK and FK), AuthorName, etc. 

Sau đó, nếu bạn muốn, bạn có thể xây dựng hai quan điểm xung quanh họ :

V_UserStories: StoryId, StoryText, UserId, etc. 
V_ClassicStories: StoryId, StoryText, AuthorName, etc. 

Với thiết lập này, bạn sẽ không lãng phí bất kỳ cột nào, bạn vẫn giữ riêng hai câu chuyện một cách hợp lý nếu bạn cần chúng.

Answer 2

Để đưa ra quyết định như vậy, bạn phải suy nghĩ nếu trường bạn muốn chèn vào bảng của bạn cho bảng của bạn chỉ và không có gì khác. ví dụ

Câu chuyện và loại câu chuyện, nếu một câu chuyện có thể có nhiều loại câu chuyện và/hoặc loại cho một số câu chuyện thì bạn phải tạo một loại lịch sử cụ thể, nhưng nếu chỉ có một loại câu chuyện một câu chuyện sau đó bạn chèn các loại thông tin (tên, mô tả vv ...) trực tiếp vào bảng câu chuyện.