Cơ sở dữ liệu quan hệ được thiết kế để lưu trữ nhiều hàng trên mỗi bảng. Có rất nhiều cơ chế để tạo điều kiện cho các bảng lớn, chẳng hạn như:
- Lập chỉ mục trên bất kỳ tổ hợp trường nào để tăng tốc độ tìm kiếm
- Bộ nhớ đệm của trang để các trang thường được sử dụng vẫn còn trong bộ nhớ
- Phân vùng theo chiều dọc (cơ sở dữ liệu dạng cột) để có các yêu cầu tốc độ cao hơn
- Các thuật toán nâng cao như kết hợp băm và chia theo nhóm (ít nhất là trong cơ sở dữ liệu không phải MySQL)
- Sử dụng nhiều bộ xử lý và đĩa để xử lý các truy vấn
Có một điều khó khăn hơn khi đưa dữ liệu vào một bảng duy nhất, đó là bảo mật. Và, trên thực tế, trong một số trường hợp, đây là mối quan tâm chính và về cơ bản yêu cầu dữ liệu phải nằm trong bảng riêng biệt. Những ứng dụng đó rất hiếm và khác xa.
Để đưa ra một ví dụ về mức độ tồi tệ khi lưu trữ dữ liệu trong nhiều bảng, hãy tưởng tượng rằng trong hệ thống của bạn, bạn có một bản ghi cho mỗi công ty và bạn lưu trữ nó trong một bảng. Bản ghi này lưu trữ thông tin về công ty - chẳng hạn như tên, địa chỉ, bất cứ thứ gì. Cuộc gọi là 100 byte thông tin.
Trong lược đồ của bạn có một bảng riêng cho mỗi "công ty", do đó mỗi bảng là một hàng. Bản ghi đó sẽ nằm trên một trang dữ liệu. Một trang dữ liệu có thể là 16 kbyte, vì vậy bạn đang lãng phí khoảng 15,9 kbyte để lưu trữ dữ liệu này. Lưu trữ 1000 bản ghi như vậy chiếm 16 Mbyte thay vì khoảng 7 trang có giá trị (112 Kbyte). Đó có thể là một hiệu suất đáng kể.
Ngoài ra, với nhiều bảng, bạn không tính đến những thách thức trong việc duy trì tất cả các bảng và đảm bảo tính chính xác của dữ liệu trong các bảng khác nhau. Các bản cập nhật bảo trì cần được áp dụng cho hàng nghìn bảng, thay vì một số ít bảng.
