Đây có phải là thiết kế cơ sở dữ liệu "đúng" không?

Question

Tôi đang làm việc với phiên bản mới của ứng dụng của bên thứ ba. Trong phiên bản này, cấu trúc cơ sở dữ liệu được thay đổi, họ nói "để cải thiện hiệu suất".

Các phiên bản cũ của DB có một cấu trúc chung như thế này:

TABLE ENTITY 
(
    ENTITY_ID, 
    STANDARD_PROPERTY_1, 
    STANDARD_PROPERTY_2, 
    STANDARD_PROPERTY_3, 
    ... 
) 

TABLE ENTITY_PROPERTIES 
(
    ENTITY_ID, 
    PROPERTY_KEY, 
    PROPERTY_VALUE 
) 

vì vậy chúng tôi đã có một bảng chính với các lĩnh vực cho các thuộc tính cơ bản và một bảng riêng biệt để quản lý các thuộc tính tùy chỉnh thêm bởi người dùng.

Phiên bản mới của DB insted có cấu trúc như thế này:

TABLE ENTITY 
(
    ENTITY_ID, 
    STANDARD_PROPERTY_1, 
    STANDARD_PROPERTY_2, 
    STANDARD_PROPERTY_3, 
    ... 
) 

TABLE ENTITY_PROPERTIES_n 
(
    ENTITY_ID_n, 
    CUSTOM_PROPERTY_1, 
    CUSTOM_PROPERTY_2, 
    CUSTOM_PROPERTY_3, 
    ... 
) 

Vì vậy, bây giờ khi người dùng thêm một thuộc tính tùy chỉnh, một cột mới sẽ được thêm vào ENTITY_PROPERTY bảng hiện tại cho đến khi số max của cột (được quản lý bởi ứng dụng) đạt được, sau đó một bảng mới được tạo ra.

Vì vậy, câu hỏi của tôi là: Đây có phải là cách chính xác để thiết kế cấu trúc DB không? Đây có phải là cách duy nhất để "tăng hiệu suất" không? Cấu trúc cũ yêu cầu nhiều người tham gia hoặc chọn lựa phụ, nhưng cấu trúc này dường như không phải tôi rất thông minh (hoặc thậm chí chính xác) ...

Answer 1

Tôi đã thấy điều này được thực hiện trước đây trên giả định (thường không được chứng minh) "chi phí" khi tham gia - về cơ bản là chuyển một bảng dữ liệu hàng nặng thành một bảng có nhiều cột. Họ chạy vào giới hạn riêng của họ, như bạn ngụ ý, bằng cách tạo ra các bảng mới khi họ chạy ra khỏi cột.

I hoàn toàn không đồng ý với nó.

Cá nhân, tôi sẽ gắn bó với cấu trúc cũ và đánh giá lại các vấn đề về hiệu suất. Đó không phải là nói cách cũ là cách chính xác, nó chỉ là tốt hơn so với "cải tiến" theo ý kiến ​​của tôi, và loại bỏ sự cần thiết phải làm lại quy mô lớn của các bảng cơ sở dữ liệu và mã DAL.

Những bảng này đánh tôi phần lớn là tĩnh ... caching sẽ là cải thiện hiệu suất tốt hơn nữa mà không làm hỏng cơ sở dữ liệu và tôi sẽ xem xét trước tiên. Thực hiện tìm nạp "đắt tiền" một lần và dính nó vào bộ nhớ ở đâu đó, sau đó quên đi những rắc rối của bạn (lưu ý, tôi đang làm cho nhu cầu quản lý Cache, nhưng dữ liệu tĩnh là một trong những cách dễ quản lý nhất).

Hoặc, chờ ngày bạn chạy vào số lượng tối đa của bảng mỗi cơ sở dữ liệu :-)

Những người khác đã đề nghị cửa hàng hoàn toàn khác nhau. Đây là một khả năng hoàn hảo khả thi và nếu tôi không có cấu trúc cơ sở dữ liệu hiện có, tôi cũng sẽ xem xét nó. Điều đó nói rằng, tôi thấy không có lý do tại sao cấu trúc này không thể phù hợp với một RDBMS. Tôi đã thấy nó được thực hiện trên hầu như tất cả các ứng dụng quy mô lớn tôi đã làm việc trên.Điều thú vị là, tất cả họ đều đã đi xuống một tuyến đường tương tự và tất cả đều chủ yếu là triển khai "thành công".

Answer 2

Tôi tin rằng việc tạo một bảng mới cho mỗi thực thể để lưu trữ các thuộc tính là một thiết kế tồi khi bạn có thể kết thúc cơ sở dữ liệu với các bảng. Chuyên nghiệp duy nhất để áp dụng phương thức thứ hai là bạn không đi qua tất cả các hàng dư thừa không áp dụng cho thực thể được chọn. Tuy nhiên, việc sử dụng các chỉ mục trên cơ sở dữ liệu của bạn trên bảng ENTITY_PROPERTIES ban đầu có thể giúp ích rất nhiều với hiệu suất.

Cá nhân tôi sẽ gắn thiết kế ban đầu của bạn, áp dụng chỉ mục và để cho cơ sở dữ liệu xác định phương pháp tốt nhất để chọn dữ liệu thay vì tách từng thuộc tính thực thể thành bảng mới.

Answer 3

Từ những gì tôi biết về cơ sở dữ liệu (nhưng tôi chắc chắn không phải là người có kinh nghiệm nhất), có vẻ như một ý tưởng tồi khi làm điều đó trong cơ sở dữ liệu của bạn. Nếu bạn đã biết số lượng thuộc tính tùy chỉnh tối đa mà người dùng có thể có, tôi muốn nói bạn nên đặt số cột của cột thành giá trị đó.

Sau đó, một lần nữa, tôi không phải là một chuyên gia, nhưng làm cho các cột mới trên bay không phải là loại cơ sở dữ liệu hoạt động như thế nào. Nó sẽ mang lại cho bạn nhiều rắc rối hơn bất cứ điều gì.

Nếu tôi là bạn, tôi sẽ sửa số lượng thuộc tính tùy chỉnh hoặc gắn với hệ thống cũ.

Answer 4

Không, không phải. Kinh khủng thật.

cho đến khi đạt đến số cột tối đa (được xử lý bởi ứng dụng), thì tạo bảng mới.

Câu này nói lên tất cả. Trong mọi trường hợp, một ứng dụng sẽ tự động tạo các bảng. Cách tiếp cận "cũ" cũng không lý tưởng, nhưng vì bạn có yêu cầu cho phép người dùng thêm các thuộc tính tùy chỉnh, nên nó phải giống như thế này.

Hãy xem xét điều này:

• Bạn mất tất cả các loại an toàn như bạn phải lưu trữ tất cả các giá trị trong cột "PROPERTY_VALUE"
• Tùy thuộc vào người dùng của bạn, bạn có thể có họ thay đổi schema trước và sau đó cho phép họ chạy một số loại công việc hàng loạt cơ sở dữ liệu cập nhật, vì vậy ít nhất tất cả các thuộc tính sẽ được khai báo trong kiểu dữ liệu bên phải. Ngoài ra, bạn có thể mất entity_id/điều quan trọng.
• Khám phá điều này: http://en.wikipedia.org/wiki/Inner-platform_effect. Điều này chắc chắn reeks của nó
• Có lẽ một RDBMS không phải là điều đúng cho ứng dụng của bạn. Xem xét sử dụng kho khóa/giá trị dựa trên như MongoDB hoặc một cơ sở dữ liệu NoSQL khác. (http://nosql-database.org/)

Answer 5

Không có cách "đúng" để thiết kế cơ sở dữ liệu - Tôi không biết bộ tiêu chuẩn được công nhận rộng rãi ngoài lý thuyết "normal form" nổi tiếng; nhiều thiết kế cơ sở dữ liệu bỏ qua tiêu chuẩn này vì lý do hiệu suất.

Có nhiều cách để đánh giá thiết kế cơ sở dữ liệu mặc dù - hiệu suất, bảo trì, thông minh, v.v. Khá thường xuyên, bạn phải giao dịch với nhau; đó là những gì thay đổi của bạn dường như đang làm - giao dịch bảo trì và dễ hiểu chống lại hiệu suất.

Vì vậy, cách tốt nhất để tìm hiểu xem đó có phải là một giao dịch tốt hay không là xem liệu hiệu suất đạt được đã được thực hiện hay chưa. Cách tốt nhất để tìm ra điều đó là tạo lược đồ được đề xuất, tải nó bằng một tập dữ liệu đại diện và viết các truy vấn bạn sẽ cần để chạy trong sản xuất.

Tôi đoán rằng thiết kế mới sẽ không được perceivably nhanh hơn cho các truy vấn như "tìm STANDARD_PROPERTY_1 từ tổ chức nơi STANDARD_PROPERTY_1 = 'chuối'.

Tôi đoán nó sẽ không perceivably nhanh hơn khi lấy toàn bộ tài sản đối với một thực thể nhất định, trên thực tế, nó có thể hơi chậm hơn, bởi vì thay vì chỉ một lần gia nhập ENTITY_PROPERTIES, thiết kế mới yêu cầu tham gia vào một vài bảng.Bạn sẽ trả về kết quả "thưa thớt" - có lẽ không phải tất cả các thực thể sẽ có giá trị trong cột property_n trong tất cả các bảng ENTITY_PROPERTIES_n.

Trường hợp thiết kế mới có thể nhanh hơn đáng kể khi bạn cần một hợp chất có mệnh đề về thuộc tính tùy chỉnh. Ví dụ, tìm một thực thể mà thuộc tính tùy chỉnh 1 là true, thuộc tính tùy chỉnh 2 là chuối và thuộc tính tùy chỉnh 3 không có trong ('kylie', 'búp bê pussycat', 'hươu cao cổ') là e` (có thể) nhanh hơn khi bạn có thể chỉ định các cột trong bảng ENTITY_PROPERTIES_n thay vì các hàng trong bảng ENTITY_PROPERTIES. Có lẽ.

Để bảo trì - yuck. Mã truy cập cơ sở dữ liệu của bạn bây giờ cần phải thông minh hơn nhiều, biết bảng nào chứa thuộc tính nào và có bao nhiêu cột quá nhiều. Khả năng lỗi giải trí cao - có nhiều phần chuyển động hơn và tôi không thể nghĩ ra bất kỳ kiểm tra đơn vị rõ ràng nào để đảm bảo rằng logic truy cập cơ sở dữ liệu đang hoạt động.

Tính dễ hiểu là một mối quan tâm khác - giải pháp này không nằm trong hầu hết hộp công cụ của nhà phát triển, nó không phải là một mẫu chuẩn công nghiệp. Các giải pháp cũ là khá phổ biến được biết đến - thường được gọi là "thực thể-thuộc tính-giá trị". Điều này trở thành một vấn đề lớn đối với các dự án tồn tại lâu dài, nơi bạn không thể đảm bảo rằng nhóm phát triển ban đầu sẽ bị treo xung quanh.