Nếu, như đã nêu trong bài đăng của bạn, ý định là tạo ra một cơ sở dữ liệu quan hệ (RDB cho ngắn gọn) và do đó, người ta hy vọng rằng nó hoạt động như vậy, câu trả lời ngắn gọn là:
- Không, bạn không nên bỏ qua các ràng buộc toàn vẹn dữ liệu .
Mục tiêu chính phải là quản lý dữ liệu thích hợp vì nó là một tài sản tổ chức khá có giá trị và một cách đáng tin cậy để đạt được mục tiêu nói trên là sử dụng các phương tiện kỹ thuật được hỗ trợ trên lý thuyết âm thanh.
Do đó, là các chuyên gia cơ sở dữ liệu, bạn có thể tận dụng các cơ chế mô hình quan hệ hiện đại và thanh lịch do Tiến sĩ EF Codd cung cấp để thực thi các quy tắc kinh doanh và tránh các vấn đề cuối cùng sẽ phát sinh nếu chúng không được sử dụng.
Về mặt này, tôi sẽ chia sẻ (a) tổng thể của tôi về các ràng buộc và cũng (b) một số cân nhắc về tình trạng của cơ sở dữ liệu và môi trường làm việc có vấn đề như sau.
Ràng buộc FOREIGN KEY, mối quan hệ dữ liệu và tính toàn vẹn tham chiếu
RDB phải phản ánh các đặc điểm của bối cảnh kinh doanh với độ chính xác cao, điều này chắc chắn đòi hỏi một phân tích cấp độ khái niệm sâu sắc được dẫn dắt bởi một nhà mô hình hoặc nhà thiết kế tuân theo các thực tiễn tốt nhất, với sự hỗ trợ không thể thiếu của các chuyên gia kinh doanh. Phân tích đó phải mang lại sự xác định chính xác và xây dựng các quy tắc kinh doanh áp dụng .
Do đó, nếu một nhà lập mô hình như vậy đã xác định rằng có tồn tại mối tương quan giữa dữ liệu liên quan, họ phải cấu hình các hạn chế mức logic tương ứng để hệ thống quản lý cơ sở dữ liệu (DBMS) có thể đảm bảo rằng dữ liệu vẫn phù hợp với các đặc điểm chính xác và quy tắc xác định trong phân tích được đề cập ở trên mọi lúc .
Về cơ sở dữ liệu đang thảo luận, người ta có thể suy ra rằng mối quan hệ tương quan thích hợp đã được xác định, vì bạn đề cập rằng có một nỗ lực thủ tục (và dễ dàng phá vỡ) để thực thi chúng từ bên ngoài các cơ sở DBMS, bằng cách sử dụng mã chương trình ứng dụng (mà là một cách tiếp cận tiền quan hệ) mà trong mọi trường hợp, phải chạm vào cơ sở dữ liệu để cố gắng xác thực tính toàn vẹn của các mối quan hệ tương tác đã nói.
Tuy nhiên, như bạn đã biết, đó không phải là kỹ thuật tối ưu để bảo vệ tính toàn vẹn tham chiếu , bởi vì khoa học quan hệ đã quy định một công cụ rất mạnh cho mục đích này, tức là các ràng buộc FOREIGN KEY (FK). Những ràng buộc này rất dễ tạo ra (thông qua cách tiếp cận khai báo ưu việt) vì chúng là những câu đơn tránh sử dụng các thủ tục ad hoc không cần thiết và dễ bị lỗi. Rất hữu ích khi lưu ý rằng tốc độ thực thi của các ràng buộc FK đã được tối ưu hóa cao bởi các lập trình viên chuyên ngành (và các nhà cung cấp nền tảng chính đã làm việc với nó trong nhiều thập kỷ nay).
Hơn nữa, vì RDB phải là một thành phần phần mềm độc lập (tự bảo vệ, tự mô tả, v.v.) có khả năng được truy cập bởi nhiều chương trình ứng dụng (máy tính để bàn, tự động, web, di động, kết hợp của chúng), nên không nên Đã kết hợp với nhau với mã của bất kỳ ứng dụng nào.
Tương tự như vậy, dữ liệu xuất hiện trong một nguồn tài nguyên tổ chức quan trọng, tự nhiên có xu hướng vượt xa các chương trình ứng dụng, lập trình viên ứng dụng, nền tảng phát triển ứng dụng và mô hình lập trình.
Các ràng buộc chính PRIMARY và ý nghĩa của các hàng trùng lặp
Khi nói một cách dễ hiểu, một loại điều cụ thể đã được coi là có ý nghĩa trong môi trường kinh doanh, một người lập mô hình cơ sở dữ liệu phải (1) xác định các đặc điểm có liên quan của nó, Wapie, thuộc tính của nó, xác nhận loại điều đó như một nguyên mẫu thực thể - tức là, một loại thực thể và và (2) thể hiện nó bằng một bảng được tích hợp bởi một hoặc nhiều cột trong một thiết kế logic.
Sau đó, giống như điều tối quan trọng để phân biệt từng trường hợp riêng lẻ của một loại thực thể nhất định trong thế giới thực, mỗi hàng được bao trong một bảng cũng phải được phân biệt duy nhất. Nếu một bảng không có bất kỳ KEY nào được khai báo, cuối cùng nó sẽ giữ lại các bản sao và nếu có hai hoặc nhiều hàng giữ chính xác cùng một giá trị, thì tất cả chúng đều mang cùng một nghĩa , tất cả chúng đều đại diện cho cùng một thực tế .
Vào thời điểm đó, các hàng trùng lặp nên được loại bỏ do nhiều lý do. Từ góc độ lý thuyết, nhà thiết kế phải đảm bảo rằng mỗi hàng luôn là duy nhất cho mục đích có các bảng hoạt động tương tự như ngôn ngữ phụ dữ liệu SQL cho phép (có tác động quan trọng đối với các hoạt động thao tác dữ liệu). Ngoài ra, từ góc độ thông tin, nếu nhiều hàng đại diện cho cùng một thực tế, việc ghi âm của chúng không chỉ thừa mà còn có hại , như dưới đây được minh họa:
- Giả sử rằng ai đó đã chèn hai hàng giống hệt nhau trong một bảng nhất định.
- Sau đó, một người khác đến và chỉ cập nhật một lần xuất hiện của các bản sao. Kết quả là, sự xuất hiện khác không được cập nhật nữa.
- Kế tiếp, một người khác cập nhật sự xuất hiện chưa được sửa đổi cho đến nay. Theo cách này, cả hai bản sao đã trải qua những thay đổi khác nhau tại các thời điểm khác nhau.
- Sau đó, khi ai đó quan tâm đến việc chọn thông tin được truyền tải bởi các hàng trong câu hỏi, anh ấy hoặc cô ấy có thể tìm thấy hai phiên bản khác nhau.
Theo cách này:
- Phiên bản nào có thể được coi là phiên bản chính xác, đáng tin cậy?
- Cái nào phản ánh chính xác thế giới thực?
Như bạn đã biết, hiện tượng này thậm chí có thể có ý nghĩa pháp lý, một tình huống chắc chắn có tầm quan trọng rất lớn.
Bên cạnh đó, thời gian và nỗ lực phải được sử dụng để xử lý những mâu thuẫn đó (có lẽ thông qua một số loại đồng bộ hóa cập nhật khác của LINE) nên được dành cho các nhiệm vụ thực sự tạo ra giá trị cho tổ chức của bạn. Vì vậy, việc giữ lại các hàng mâu thuẫn phải được tránh bằng thiết kế để giữ nguyên tính nhất quán của cơ sở dữ liệu.
Đó là lý do tại sao việc xác định một PRIMARY KEY (PK) và khai báo các ràng buộc tương ứng phải luôn được thực hiện bởi người thiết kế cơ sở dữ liệu. Nhưng cũng phải đề cập rằng một bảng có thể có nhiều hơn một cột hoặc tổ hợp các cột chứa các giá trị xác định duy nhất mỗi hàng; do đó, bên cạnh việc thiết lập ràng buộc PK (được thiết lập lý tưởng là CHÍNH vì lý do thực dụng), nhà thiết kế cũng phải khai báo một hoặc nhiều KHÓA THAY ĐỔI (thường được xác định thông qua một hoặc nhiều ràng buộc KHÔNG GIỚI HẠN) khi áp dụng (đó là khá phổ biến).
Một đặc tính thuận lợi khác của PK là, khi di chuyển vào các bảng khác để tham gia vào các FK đơn hoặc hỗn hợp, chúng có thể giúp thực thi các tỷ lệ chính của các mối quan hệ tồn tại giữa các dữ liệu. Tất cả điều này, vâng, bằng các cài đặt khai báo đơn giản và hiệu quả, được đảm bảo bởi DBMS.
(Hiện tại) KIỂM TRA ràng buộc và xác thực một hàng
Chúng ta đừng quên về sự liên quan của các ràng buộc KIỂM TRA (hiện tại), hạn chế khai báo bộ giá trị cột hợp lệ của một hàng (có vẻ đơn giản, nhưng thực tế là một tính năng cơ bản của DBMS quan hệ), cũng giúp thực hiện chắc chắn rằng các quy tắc của bối cảnh kinh doanh được phản ánh với độ chính xác mọi lúc.
Khi bạn đánh dấu câu hỏi của mình bằng thẻ MySQL, phải nói rằng, thật không may, một nền tảng như vậy cho phép tuyên bố loại ràng buộc nói trên, nhưng đồng thời, bỏ qua việc thực thi! , tình hình đó, có thể hiểu được, đã được báo cáo là một lỗi từ năm 2004 .
Về vấn đề này, bạn sẽ phải quan tâm đến yếu tố này bằng các phương tiện khác, ví dụ: GIAO DỊCH ACID , TRIGGERS hoặc các phương thức khác trong chính DBMS (xem câu trả lời này của @ ypercubeᵀᴹ
để biết thông tin về chủ đề này) để dữ liệu tiếp tục hãy kiên định
Ràng buộc xác nhận: thiết lập thêm các quy tắc kinh doanh nhiều hàng và nhiều bảng
Một khía cạnh mà vì bất kỳ lý do gì đều hỗ trợ rất kém cho cácififif của các DBMS khác nhau, bao gồm cả MySQL, đang cho phép các ràng buộc nhiều hàng và nhiều bảng trong một PK và FK thời trang khai báo, rõ ràng là.
Về phần mình, tiêu chuẩn SQL bao gồm các CHỨNG NHẬN từ nhiều năm nay. Tôi không biết quy tắc nào trong môi trường kinh doanh của bạn sẽ được hưởng lợi từ cách tiếp cận xác thực mức logic đó, nhưng, với tư cách là người thiết kế cơ sở dữ liệu, tôi cho rằng sẽ rất tiện khi ràng buộc dữ liệu với một hoặc nhiều ĐÁNH GIÁ, mặc dù tôi phải đề cập đến điều đó từ quan điểm của các nhà phát triển DBMS, loại công cụ tối quan trọng này đã khó thực hiện ở mức độ trừu tượng hóa vật lý.
Dường như nhà cung cấp và / hoặc nhà phát triển của Oracle đang đánh giá hỗ trợ ASSERTION kể từ năm 2016 và điều đó sẽ khiến DBMS tuân thủ quan hệ hơn và do đó, mạnh mẽ và cạnh tranh hơn. Tôi đoán rằng, nếu (i) người tiêu dùng của họ tiếp tục thúc đẩy và (ii) Oracle thành công trong việc triển khai, thì (iii) các nhà cung cấp / cộng đồng DBMS khác cũng sẽ phải cho phép họ và việc sử dụng của họ sẽ bắt đầu lan rộng. Chắc chắn, đó sẽ là một tiến bộ lớn trong lĩnh vực quản lý cơ sở dữ liệu và là một trong những công cụ đặc biệt nhất được hình dung bởi Tiến sĩ Codd, cá nhân tôi hy vọng rằng chúng ta sẽ sớm thấy điều đó xảy ra.
Thống nhất dữ liệu và quá trình ra quyết định
Như đã thảo luận ở trên, một trong những khía cạnh quan trọng nhất của RDB là nó tự bảo đảm tính nhất quán của dữ liệu mà nó giữ lại và tính nhất quán chỉ được đáp ứng khi RDB tuân thủ các ràng buộc toàn vẹn được tuyên bố bởi nhà mô hình hóa.
Về mặt này, bắt buộc phải có các bảng cơ sở (những bảng được thiết lập trong cấu trúc DDL) mà tính toàn vẹn được bảo vệ để có thể tạo các bảng dẫn xuất (ví dụ: một câu lệnh CHỌN hoặc khung nhìn lấy các cột từ nhiều bảng) đáng tin cậy , bởi vì các bảng dẫn xuất phải được sản xuất nhất thiết theo các bảng cơ sở.
Người ta biết rằng mọi người sử dụng thông tin làm công cụ chính trong quá trình ra quyết định của tổ chức (và thông thường). Sau đó, nếu thông tin được trình bày bởi cơ sở dữ liệu không mạch lạc và chính xác, các quyết định dựa trên thông tin đó sẽ không có giá trị (để nói rằng ít nhất). Đó là lý do tại sao một RDB phải được thiết kế và triển khai cẩn thận: nó phải được xây dựng để trở thành một tài nguyên đáng tin cậy có thể hỗ trợ người dùng đưa ra các quyết định có căn cứ.
Chuẩn hóa
Than ôi, cơ sở dữ liệu 'không chuẩn hóa' nhanh hơn cơ sở dữ liệu bình thường hóa là một quan niệm sai lầm được lan truyền rộng rãi, mặc dù đó cũng là một lập luận có thể bác bỏ trên cơ sở logic, vật lý và thực dụng.
Thứ nhất, không chuẩn hóa ngụ ý rằng một bảng cơ sở đã được chuẩn hóa trước đó (nhờ quy trình chính thức , dựa trên cơ sở khoa học, được thực hiện ở mức độ trừu tượng logic của cơ sở dữ liệu).
Vì vậy, giả sử rằng bảng đã nói trên thực tế đã được chuẩn hóa một cách chính xác, thì việc không chuẩn hóa chính xác nó (điều này trái ngược với ý nghĩa chính thức của từ này, liên quan đến việc gắn vào các cột thuộc và cũng là một phần của các bảng khác trong quảng cáo thời trang hoc ) có thể hỗ trợ, ví dụ, để tăng tốc (ở cấp độ vật lý) việc xử lý chỉ một hoặc một vài câu lệnh CHỌN cụ thể, đồng thời, quá trình hành động đó có thể làm suy yếu việc thực thi nhiều dữ liệu liên quan khác các thao tác thao tác (ví dụ: một số câu lệnh INSERT, UPDATE, DELETE và SELECT hoặc các kết hợp của chúng được đính kèm trong một hoặc nhiều GIAO DỊCH ACID).
Ngoài ra, việc không chuẩn hóa (có thể là chính thức hoặc không chính thức) sẽ đưa ra các bất thường cập nhật / sửa đổi làm suy giảm sự gắn kết của cơ sở dữ liệu, một vấn đề mà điều đó có thể được xử lý bởi các thủ tục phức tạp, tốn kém và dễ bị lỗi, khi tất cả điều này có thể được ngăn chặn sự khởi đầu
Giàn giáo ở cấp độ vật lý hỗ trợ các bảng bình thường hóa và không chuẩn hóa
Bố cục logic (trừu tượng) (thiết kế SQL-DDL) có nghĩa là được sử dụng trong thế giới thực rõ ràng giữ các hậu quả vật lý (cụ thể) phải được xem xét.
Theo cách này, một bảng không được chuẩn hóa của Viking sẽ nhất thiết phải là rộng hơn (giữ các cột bổ sung), điều đó có nghĩa là các hàng của nó sẽ nặng hơn (yêu cầu các thành phần cấp vật lý lớn hơn và lớn hơn), do đó có nghĩa là các quy trình tính toán cơ bản (ví dụ , những thứ phải làm với ổ cứng hoặc bộ nhớ) có thể dễ dàng quay chậm hơn.
Ngược lại, một bảng được chuẩn hóa, tất nhiên, đó là phần tử hẹp hơn (có ít cột hơn) sẽ là một phần tử nhẹ hơn (được phục vụ bởi các thành phần vật lý nhỏ hơn và nhỏ hơn) mà hành xử nhanh hơn, giúp tăng tốc chuỗi các hành động liên quan đến , ví dụ, viết và đọc dữ liệu.
Do đó, rất thuận tiện để (a) bình thường hóa các bảng có liên quan một cách chính thức và thận trọng, giữ chúng như vậy, và sau đó (b) sử dụng bất kỳ tài nguyên cấp vật lý nào có thể tối ưu hóa tốc độ truy xuất và sửa đổi dữ liệu, ví dụ: một chiến lược lập chỉ mục cẩn thận và hiệu quả, cho phép cấu hình máy chủ phần mềm và phần cứng phù hợp, nâng cấp khả năng băng thông mạng, v.v.
Chức năng của cơ sở dữ liệu đang được xem xét
Các đoạn sau của câu hỏi của bạn phải làm với tốc độ của các hoạt động truy xuất dữ liệu:
[A] là sản phẩm mà thành công, có thể do dự, nâng cao cơ sở dữ liệu; tuy nhiên, điều đầu tiên tôi nhận thấy là một trang mất 1 phút để tải (vâng, 60 giây!).
Nếu tải của một trang nhất định mất nhiều như vậy, rõ ràng là người dùng hệ thống không nhận được dịch vụ tốt; do đó, ngay cả khi nó hoạt động, thì chức năng của nó dường như không tối ưu chút nào, điều đó chứng tỏ rằng ý định của bạn để làm cho toàn bộ môi trường (cơ sở dữ liệu và ứng dụng) hiệu quả hơn được duy trì tốt và thể hiện thái độ rất xây dựng.
Sau đó, ngay cả khi khoa học chắc chắn hỗ trợ bạn và do đó bạn nên duy trì một tư thế vững chắc, tôi khuyên bạn nên tiếp cận tình huống theo cách ngoại giao, vì vào cuối ngày, chủ nhân, đồng nghiệp và chính bạn đang THAM GIA nỗ lực để tạo ra toàn bộ tổ chức thành công hơn. Vì vậy, đó là một lập luận mà bạn nên nhấn mạnh, rằng, trong khi họ đang làm những việc khác tốt hơn, cải thiện thực tiễn quản lý dữ liệu chung và cụ thể có thể giúp đáng kể trong việc tạo ra sự tăng trưởng của tổ chức và cá nhân.
Hầu hết các truy vấn có liên quan bao gồm các hoạt động THAM GIA, khiến chúng chạy rất, rất, rất chậm với lượng dữ liệu lớn (cơ sở dữ liệu chứa hàng triệu hàng).
Điều đáng lưu ý là toán tử THAM GIA là một yếu tố thiết yếu và mạnh mẽ liên quan đến thao tác dữ liệu quan hệ. Sau đó, mặc dù các nền tảng mạnh hơn phục vụ nó với các thực thi tương đối nhanh hơn, hoàn cảnh bạn mô tả rất có thể là một triệu chứng của một thiết kế không hiệu quả (ở mức độ trừu tượng về mặt khái niệm, logic và vật lý). Vì vậy, ước tính tầm nhìn đầu tiên của tôi là:
- Cài đặt INDEX có thể yêu cầu cải tiến.
- Các định nghĩa về kích thước và loại cột PK và FK cần được xem xét (và tôi hoàn toàn đồng ý với @Rick James về các cân nhắc PK của anh ấy , vì các KEY tổng hợp có xu hướng hiệu quả hơn nhiều so với các đại diện được bổ sung trong các trường hợp thích hợp).
- Chuẩn hóa hơn nữa (chính thức, dựa trên khoa học) có thể giúp giảm bớt những vấn đề này, vì thực tế là, trong trường hợp phù hợp (nghĩa là được thực hiện trong RDB được thiết kế tốt), THAM GIA được thực hiện rất nhanh .
Hơn nữa, vâng, như @TommCatt đề cập trong câu trả lời của anh ấy , đôi khi việc viết lại (logic) của một truy vấn sẽ sửa đổi kế hoạch thực hiện (vật lý) của nó để tăng tốc đọc / ghi dữ liệu, đây là một yếu tố cần được tính đến.