Là quan hệ chậm hơn một bảng lớn, không hiệu quả?

Tôi đã được yêu cầu trong công việc của mình vi phạm hình thức bình thường đầu tiên (lặp lại các nhóm trên các cột, sử dụng các giá trị rỗng / null) nhiều lần, "vì sức mạnh xử lý của máy tính". Tóm lại, một bảng "sinh viên" nên có ít nhất 8 trường trống (ví dụ: điện thoại: phone1, phone2, phone3 ...) thay vì đề xuất của tôi - bảng "điện thoại" chứa số điện thoại (và có thể có siêu dữ liệu khác) và khóa ngoại là số id sinh viên. Sếp của tôi nói rằng tốt hơn hết là lưu trữ chúng theo cách đó vì "có ít chu kỳ CPU hơn và đó là vấn đề trong các nền tảng web", thay vì sử dụng các mối quan hệ. Tôi nói rằng, trong trường hợp xấu nhất, nó không đáng kể.

Trong ví dụ đó, sử dụng các mối quan hệ (giả sử rằng các bảng chứa rất nhiều bản ghi trong một ứng dụng web cỡ trung bình) chậm hơn đáng kể so với sử dụng loại lược đồ bảng đó?

Tôi không thấy bất cứ ai có thể đưa ra tuyên bố như vậy mà không có một số sự kiện thực tế để sao lưu nó. Nếu các truy vấn của bạn bị ràng buộc bởi CPU, thì bạn nên tìm cách giảm bớt nút thắt đó.

Nghe có vẻ như ông chủ của bạn cảm thấy rằng một cơ sở dữ liệu không chuẩn hóa sẽ hoạt động tốt nhất, nhưng tôi không biết đủ về ứng dụng của bạn để nói liệu điều đó có đúng hay không. Số lần xóa, cập nhật và chèn dự kiến ​​cho bảng này sẽ là bao nhiêu?

Tôi hy vọng rằng một thiết kế không chuẩn hóa như vậy có thể làm giảm thời gian CPU nhưng sẽ hy vọng rằng I / O đĩa của bạn sẽ tăng lên. Và đọc vật lý từ đĩa sẽ đắt hơn nhiều so với chu kỳ CPU, vì vậy có lẽ ông chủ của bạn có một số liệu rất cụ thể để đáp ứng (CPU) và kết quả là muốn có một thiết kế rất cụ thể? Nếu vậy, tôi chỉ đơn giản là xây dựng những gì được yêu cầu và giữ số liệu về chi phí CPU cho các truy vấn đang được chạy. Nếu bạn thấy sự gia tăng thời gian thì bạn có thể muốn đề xuất một số thay đổi thiết kế.

Trên thực tế, có lẽ nên lấy một danh sách tất cả các số liệu mà sếp của bạn muốn xem và theo dõi chúng theo thời gian.