Có cần thiết phải tạo một cơ sở dữ liệu với càng ít bảng càng tốt không

Chúng ta có nên tạo cấu trúc cơ sở dữ liệu với số lượng bảng tối thiểu không?

Nó có nên được thiết kế theo cách mà mọi thứ vẫn ở một nơi hay không nếu có nhiều bàn hơn?

Nó sẽ ảnh hưởng đến bất cứ điều gì?

Tôi đang hỏi câu hỏi này vì một người bạn của tôi đã sửa đổi một số cấu trúc cơ sở dữ liệu trong mediaWiki. Cuối cùng, thay vì 20 bàn, anh ta chỉ sử dụng 8 bàn, và anh ta phải mất 8 tháng để làm điều đó (đó là nhiệm vụ đại học của anh ta).

BIÊN TẬP

Tôi đang kết luận câu trả lời là: kích thước của các bảng KHÔNG quan trọng, cho đến khi trường hợp là ngoại lệ; trong trường hợp không chuẩn hóa có thể giúp đỡ.

Cảm ơn tất cả mọi người cho câu trả lời.

IGNORE số lượng bảng. Lo lắng nhiều hơn về việc thiết kế chính xác. Nếu mối quan tâm chính của bạn là số lượng bảng, có lẽ bạn không nên thiết kế hệ thống cơ sở dữ liệu.

Nếu bạn của bạn chỉ cần 8 bảng và hệ thống hoạt động tốt với điều đó, thì 8 là số chính xác và 12 bảng còn lại có thể không cần thiết cho bất cứ điều gì anh ta đang làm.

Các ngoại lệ có thể có thể là các môi trường đặc biệt có giới hạn cứng đối với số bảng, nhưng tôi không thể nghĩ ra một ví dụ cụ thể về một hệ thống như vậy ở trên đỉnh đầu của tôi.

Một cơ sở dữ liệu nên có chính xác nhiều bảng như nó cần. Không ít hơn, không hơn.

Các bảng cơ sở dữ liệu phải tuân thủ Nguyên tắc Trách nhiệm duy nhất, giống như các lớp nên. Mỗi bảng nên xử lý không quá một nhóm dữ liệu liên quan để bắt đầu. Hiệu suất sang một bên, điều này làm cho toàn bộ con thú dễ quản lý hơn, bởi vì các bảng sẽ nhỏ hơn. Điều này cũng cung cấp cho bạn hiệu suất tốt hơn vì các bảng nhỏ hơn sẽ nhanh hơn để tìm kiếm và tham gia.

Đừng lo lắng về số lượng bảng nhiều hơn bạn lo lắng về số lượng lớp học - đừng lo lắng gì cả. Tập trung vào việc tạo mã tốt, sạch, dễ đọc, chứ không phải chiếm bao nhiêu dung lượng. Tái cấu trúc mạnh mẽ một khi bạn có một sản phẩm hoạt động để làm cho nó tốt hơn - và tôi cũng có nghĩa là cơ sở dữ liệu! Bạn sẽ thấy các cột nên có trong các bảng khác hoặc không cần thiết, v.v. Hồ sơ để xem những truy vấn nào mất nhiều thời gian nhất và tại sao và giải quyết các vấn đề đó nếu chúng thực sự là một vấn đề.

Một cơ sở dữ liệu sản xuất cho một ứng dụng kinh doanh có thể chứa hàng trăm hoặc thậm chí hàng ngàn bảng. Bạn cần số lượng bảng bạn cần cho các yêu cầu kinh doanh. Cố gắng giảm số lượng bảng chỉ vì có ít bảng hơn thường sẽ dẫn đến cơ sở dữ liệu khó truy vấn hơn, có vấn đề về tính toàn vẹn dữ liệu và khó bảo trì hơn nhiều so với cơ sở dữ liệu được chuẩn hóa.

Có những lúc cần chuẩn hóa. Điều này chỉ nên được thực hiện bởi một người biết chính xác những gì cô ấy / anh ấy đang làm và tại sao. Nó rất dễ dàng để làm hỏng mệnh giá vì vậy nó chỉ nên được thực hiện bởi một chuyên gia cơ sở dữ liệu hoặc nhà phát triển ứng dụng cao cấp có nhiều năm kinh nghiệm về cơ sở dữ liệu. Một người thiếu kinh nghiệm nên cố gắng tối thiểu đạt đến hình thức bình thường thứ ba (trừ khi bạn đang làm kho dữ liệu là lĩnh vực mà tôi sẽ không xem xét việc thuê một người thiếu kinh nghiệm) trong bất kỳ cơ sở dữ liệu nào mà anh ấy / cô ấy thiết kế.

Khi mọi người nói giảm các bảng vì tham gia rất tốn kém, họ thường không biết gì hoặc có cơ sở dữ liệu được thiết kế tồi, thiếu các chỉ mục quan trọng hoặc sử dụng các khóa tự nhiên cột mulit lớn. Cơ sở dữ liệu quan hệ được thiết kế để sử dụng các phép nối và phép nối có thể khá hiệu quả nếu các FK được lập chỉ mục đúng và chúng sử dụng các trường nhỏ để tham gia (số nguyên là hiệu quả nhất). Bạn sẽ lưu ý rằng các doanh nghiệp lớn có cơ sở dữ liệu cỡ terrabyte bằng cách nào đó quản lý để có được hiệu suất tuyệt vời và sử dụng tham gia.

Không có nhà thiết kế cơ sở dữ liệu nghiêm túc nào cố gắng giảm số lượng bảng chỉ vì họ muốn có ít bảng hơn. Bạn giảm số lượng bảng vì dữ liệu không còn cần thiết hoặc bạn gặp vấn đề về hiệu suất mà bạn không thể giải quyết bằng bất kỳ cách nào khác (và có rất nhiều cách để thử trước khi gặp rủi ro lớn đối với dữ liệu của bạn về việc không chuẩn hóa bảng) .

Vì mọi trường trong cơ sở dữ liệu được xác định bởi sự kết hợp của tên bảng, tên cột, khóa chính và giá trị, bạn luôn có thể giảm số lượng bảng bằng cách không chuẩn hóa thành một bảng duy nhất lưu trữ bảng đó. Không hữu ích lắm, nhưng hoàn toàn có thể.

Bảng là một lớp trừu tượng giúp giải quyết các vấn đề về xử lý dữ liệu. Đó là lý do tại sao chúng được tạo ra. Tôi đã biến nó thành một trò đùa nhưng hiểu rằng bạn có thể giảm mọi bộ dữ liệu xuống một bảng chính ngay lập tức chỉ ra lý do tại sao bạn không nên: vì các bảng mang lại cho bạn một cái gì đó. Ở cấp độ khái niệm, chúng mang đến cho bạn một cấu trúc dễ hiểu hơn đối với con người so với dữ liệu tuần tự. Ở cấp độ giữa, họ đưa ra khái niệm chuẩn hóa: để tránh lưu dữ liệu dư thừa và đưa ra một điểm duy nhất cho các thay đổi, thay vì thay đổi một cái gì đó ở một vài nơi. Ở cấp độ kỹ thuật, cơ sở dữ liệu mang lại hầu hết những điều bạn muốn làm với dữ liệu, nhiều công cụ và thực hiện chúng và kiểm tra chúng nhiều hơn bạn có thể tự mình làm. Hãy nghĩ về các loại dữ liệu, giá trị mặc định, quyền người dùng, chỉ mục, ràng buộc khóa ngoài, v.v. Nó đã được thử nghiệm, sử dụng bởi nhiều người, được tối ưu hóa, gỡ lỗi. (Không hoàn hảo, nhưng vẫn còn.)

Vì cơ sở dữ liệu là một công cụ, điều chính là quyết định cách sử dụng công cụ. Số lượng bảng không quan trọng. Tối thiểu hóa luôn luôn có thể nhưng với chi phí bỏ đi những lợi ích. (Nếu bạn đọc thêm về bình thường, bạn sẽ bắt gặp vài trường hợp cho denormalizing - nhưng thậm chí sau đó nó là tất cả về sự đúng quyết định chứ không phải chỉ một cách mù quáng giảm số lượng các bảng.)

Bạn nên sử dụng đúng số lượng bảng. Về lý thuyết, bạn có thể thực hiện với một bảng bảng bằng cách không chuẩn hóa toàn bộ cơ sở dữ liệu, nhưng cơ sở dữ liệu sẽ không sử dụng được. Bạn của bạn có vẻ như anh ta có quá nhiều thời gian trên tay.

Có số lượng bàn tối thiểu tấn công tôi như một mục tiêu rất đặc biệt.

Chắc chắn giảm một lược đồ từ 20 bảng xuống còn 8 bảng có thể là một điều tốt (nếu được thực hiện tốt, nó có thể giảm các phép nối và tăng hiệu suất, loại bỏ các cột không sử dụng, v.v.) nhưng nó cũng có thể làm cho nó khó hiểu hơn và tăng cường tiến lên.

Nghĩ về nó theo cách khác bạn có nghĩ rằng bình thường hóa là một điều tốt? Chuẩn hóa thường dẫn đến số lượng bảng lớn hơn nhưng cũng dẫn đến các giải pháp dễ bảo trì hơn, giảm trùng lặp dữ liệu và quản lý dữ liệu dễ dàng hơn.

Tất nhiên nó cũng có thể dẫn đến hiệu suất chậm hơn (giả sử cơ sở dữ liệu không chuẩn hóa được thiết kế tốt).

Cuối cùng, bạn cần suy nghĩ về những yêu cầu của bạn trong các lĩnh vực này nhưng với tư cách là một vị trí bắt đầu mặc định tôi sẽ nói về mức độ chuẩn hóa hợp lý và sau đó xem xét liệu điều đó có gây ra vấn đề cụ thể trong đó ít bảng hơn có thể là một giải pháp hay không.

Số không quan trọng. Thiết kế là. Nhìn vào một số hệ thống ngoài kia. Magento, PHPBB, v.v. Họ có hàng tá bảng trong hệ thống của họ và hoạt động tốt.

Cùng với các mối quan tâm về chuẩn hóa và hiệu suất, bạn có thể sử dụng "sẽ yêu cầu một bảng khác" như một cách để quản lý phạm vi của một ứng dụng. Tính năng đó sẽ yêu cầu một bảng mới và tất cả thời gian, năng lượng và nỗ lực để thiết kế, xây dựng, kiểm tra, quản lý trong các bản nâng cấp và tất cả các mã hóa khác có liên quan. Thêm 5 trường vào (các) bảng hiện có (nếu thích hợp) dễ dàng hơn nhiều so với bảng 5 cột.

Nếu bạn thiết kế một cơ sở dữ liệu với việc cố gắng giảm thiểu việc tạo bảng, thì bạn sẽ sớm thấy khó khăn và sai lầm đột ngột theo cách của bạn.

Số lượng bảng không nên đi đầu trong tâm trí của bạn khi tạo một thiết kế cơ sở dữ liệu. Đặt những thứ mà họ cần để hợp lý và quan hệ đi.

Tôi nghĩ rằng số lượng bảng có vấn đề và có thể ảnh hưởng lớn đến hiệu suất nếu bạn chọn phân tách dữ liệu, cho tất cả các mục đích và mục đích kinh doanh, ở cùng nhau, thành nhiều bảng (vì vậy bạn có cơ sở dữ liệu bình thường hóa). Thông thường khi bạn làm điều này, bạn sẽ buộc phải THAM GIA các hoạt động (hoặc không tương đương với SQL) để có được tất cả dữ liệu bạn cần và cho các bảng đủ lớn có cấu trúc như thế này, hiệu suất giảm nhanh.

Tôi sẽ không đi vào chi tiết, nhưng tôi nghĩ rằng thực tế là số lượng bảng có thể ảnh hưởng đến hiệu suất là một trong những lý do tại sao các cơ sở dữ liệu noQuery như Cassandra, Mongo và Google BigTable (sic!) Đã được phát minh, và đó cũng là lý do tại sao họ khuyến khích khử chuẩn hóa dữ liệu (và do đó tránh được số lượng lớn các bảng / bộ sưu tập, v.v.).

Điều tương tự cũng có thể xảy ra đối với các máy chủ tìm kiếm như Solr của Apache không thực sự khuyến khích hoặc dễ dàng tạo điều kiện chia tài liệu của bạn thành nhiều "bảng" hoặc "loại mục nhập" khuyến khích bạn thay vào đó là một lược đồ "bao gồm tất cả" cho tất cả các loại tài liệu mà bạn muốn lập chỉ mục (và do đó tránh phải thực hiện các thao tác giống như THAM GIA).

Tôi không nói rằng thực tế đơn giản là có các bảng x trong một lược đồ nhất thiết sẽ làm cho nó chậm hơn một lược đồ với các bảng x / 2 mọi lúc, nhưng có một số bối cảnh nhất định trong đó có thể dẫn đến chậm lại do hậu quả các hoạt động bổ sung cần thiết để tổng hợp dữ liệu trong tất cả các bảng. Tiếp tục điều này tôi cũng không nghĩ rằng việc nói "bất kỳ số lượng bảng và chuẩn hóa dữ liệu cực kỳ nào cũng không ảnh hưởng gì đến hiệu suất".

Chú Bob sẽ tranh luận rằng Thêm là Đơn giản hơn.

Xem http://c2.com/cgi/wiki?FearOfAddingTables

"một thiết kế tốt thường được đơn giản hóa bằng cách thêm bảng"

Tôi tin rằng hầu hết tất cả các thực thể là nhiều-nhiều, đòi hỏi nhiều bảng hơn.

Tạo một bảng quốc gia với mã lục địa trong đó. Ồ, bạn không thể bởi vì thực sự có 8 quốc gia xuyên lục địa. Tương tự với tiền tệ. Panama sử dụng hai.

Thì câu trả lời là CÓ.

Nhưng phụ thuộc vào ý nghĩa thực sự của số lượng bảng "tối thiểu" là gì.

Ví dụ (một ví dụ chống).

Nếu tôi có các đối tượng tiếp theo

1. người dùng
2. khách hàng

và cả hai đều chia sẻ cùng một trạng thái (các trường) và không có giới hạn bảo mật sau đó, cách phù hợp hơn để thực hiện một bảng duy nhất

1. bảng_persons

thay vì hai bảng khác nhau

1. bảng_users
2. khách hàng

Nhược điểm là trong bảng_persons, chúng ta sẽ cần thêm một trường mới (type_of_person).

Sai lầm khác (sai lầm nếu không thực sự cần phải làm) là "tách" một bảng, đọc thành: tách một bảng thành hai.

1. bảng_persons

trong hai bảng

1. bảng_info_persons
2. bảng_extra_info_persons

bởi vì bạn đang buộc một số truy vấn để tham gia hai bảng và điều đó thật tệ.