RDBMS sử dụng một cách tiếp cận hoàn toàn khác nhau để lưu trữ dữ liệu hơn đối tượng hoặc phím có giá trị cơ sở dữ liệu.
Mô hình quan hệ giả định bạn không biết dữ liệu nào sẽ cần trong tương lai hoặc cách dữ liệu sẽ được truy cập trong tương lai. Điều này đã được chứng minh là một giả định khá đáng tin cậy trong kinh nghiệm của tôi.
Đó là một lý do khiến một dbms SQL sẽ cho phép bạn thêm các chỉ mục khi cần thiết và cho phép bạn thả các chỉ mục đã được chứng minh là vô ích. Nó sẽ cho phép bạn thêm các ràng buộc khi chúng trở thành các ràng buộc đã biết - đôi khi yêu cầu thêm nhiều bảng hơn - và giảm các ràng buộc khi các yêu cầu thay đổi. Nó sẽ cho phép bạn thêm các cột khi bạn khám phá thêm nhiều điều mà bạn nên biết. Nó sẽ cho phép bạn thay thế các bảng bằng các khung nhìn và thay thế các khung nhìn bằng các bảng. Một số dbms sẽ cho phép bạn tạo các khung nhìn vật chất - tác động của chúng lên tốc độ truy vấn có thể gây ấn tượng mạnh và ảnh hưởng của chúng đến việc sử dụng đĩa, tàn phá.
Cơ sở dữ liệu hữu ích mở rộng phạm vi tiếp cận của chúng. Một cơ sở dữ liệu SQL, được thiết kế theo mô hình quan hệ, làm cho nó tương đối dễ dàng để thêm các tính năng không ai mơ ước trong thiết kế ban đầu, và mà không cần nghiền các phần khác của hệ thống. Vì vậy, họ được gọi là thường được kêu gọi để làm những điều nhà thiết kế ban đầu của họ đã không tưởng tượng.
Tất cả những điều
- thêm và thả các chỉ số theo thời gian,
- thêm và thả những hạn chế theo thời gian,
- thêm và thả các cột theo thời gian,
- thêm và thả bảng theo thời gian ,
ước tính mức sử dụng đĩa trông giống như lãng phí thời gian. Bất kỳ một trong số họ một mình có thể thay đổi đáng kể không gian đĩa cần thiết cho một cơ sở dữ liệu.
Bạn có thể tính toán khoảng trống được yêu cầu bởi một hàng và một trang khá chính xác. (Hãy thử Google cho "Bố cục hàng của YourDBMSname" và "Bố cục trang của YourDBMSname".) Nhưng khi bạn cố gắng nhân với số hàng yêu cầu, bạn phải ước tính số hàng. Điều đó đặt bạn vào phần lớn những gì Steve McConnell gọi là "cone of uncertainty".
Nếu bạn chưa đo lường mức sử dụng đĩa trong nhiều dự án theo thời gian tại công ty của riêng mình, hãy ước tính tác động của các điểm bullet ở trên chỉ là đoán.
Công ty Fortune 100 cuối cùng mà tôi làm việc có cơ sở dữ liệu hoạt động đã được sản xuất từ những năm 1970. Hàng trăm ứng dụng, được viết bằng hơn 25 ngôn ngữ lập trình trong suốt 40 năm đã đạt được điều đó mỗi ngày. (Tôi nghĩ rằng nó được xây dựng trên IMS của IBM ban đầu, ngày nay nó được xây dựng trên Oracle.)
Ngay cả một vài năm trước đây, không ai tưởng tượng rằng cơ sở dữ liệu của họ sẽ được sử dụng để dịch các bản vẽ kỹ thuật và hóa đơn thành tài liệu. cũng để sản xuất các tài liệu hải quan mà họ cần để có được sản phẩm hoàn chỉnh ra khỏi Trung Quốc. Việc triển khai các tính năng mới này yêu cầu lưu trữ dữ liệu bổ sung về mọi phần và về mọi tài liệu thiết kế trong khoảng không quảng cáo trực tiếp của chúng. Sớm trong dự án đó, ước tính của chúng tôi khá xa. Đó là đầu lớn của hình nón. (Chúng tôi ước tính một số thứ, nhưng không sử dụng đĩa. Chúng tôi được yêu cầu thành công, vì vậy bất kỳ thiết kế nào tôi đưa ra, ai đó sẽ được yêu cầu cung cấp không gian đĩa cần thiết.) Nhưng khi chúng tôi phát trực tiếp, chúng tôi biết giá trị chính xác cho mọi ước tính, bởi vì chúng tôi đã thực hiện công việc. (Đó là đầu hẹp của hình nón.)
Vì vậy, làm thế nào để bạn giảm thiểu nguy cơ phỏng đoán trong môi trường thiết kế và triển khai cơ sở dữ liệu? Tham gia bài học từ năm 1972.
Tạo mẫu thử nghiệm và đo lường.
kỹ sư Hóa học từ lâu rằng một quá trình làm việc trong phòng thí nghiệm không thể được thực hiện trong một nhà máy ở chỉ một bước. An bước trung gian được gọi là nhà máy thí điểm thí điểm là cần thiết để cung cấp cho trải nghiệm trong việc mở rộng số lượng và hoạt động trong môi trường không bảo vệ . . . .
. . . Dự án sau khi dự án thiết kế một bộ thuật toán và sau đó lao vào xây dựng phần mềm do khách hàng phân phối theo lịch trình yêu cầu phân phối thứ đầu tiên được xây dựng. . . .
Câu hỏi quản lý, do đó, không phải là cho dù để xây dựng hệ thống thí điểm và vứt đi. Bạn sẽ làm điều đó. Câu hỏi duy nhất là liệu có nên lập kế hoạch trước để xây dựng một trò ném bóng hay hứa sẽ chuyển giao cho khách hàng.
Fred Brooks, Jr., trong The Mythical Man-Month, p 116.
Tại sao bạn sẽ muốn tính toán rằng khi thiết kế một sơ đồ .. mà nghe như một điều bất hợp lý để cố gắng kể từ khi chỉ một mình lược đồ sẽ không xác định được kích thước cơ sở dữ liệu. Cũng xem xét rằng chi phí không gian lưu trữ sẽ là yếu tố quan trọng nhất cho tổng chi phí của ví dụ. chọn cơ sở dữ liệu bạn cần. –
@ManfredMoser, lược đồ cơ sở dữ liệu là phần thiết kế dữ liệu ứng dụng của bạn. Làm thế nào nó được xây dựng cho thấy những gì kế hoạch của bạn là để lưu trữ dữ liệu. – Xeoncross
Có ..nhưng rất nhiều yếu tố khác sẽ ảnh hưởng đáng kể đến lưu trữ để bất kỳ đánh giá nào từ lược đồ mà không yêu cầu thêm như hiệu năng (caching, indexes ..) hoặc truy vấn (kho dữ liệu trên đầu trang của OLTP) trở nên hoàn toàn vô nghĩa ... lãng phí thời gian của bạn. –