9 lỗi thiết kế cơ sở dữ liệu phổ biến nhất

Có thể bạn đã mắc một số sai lầm này khi bắt đầu sự nghiệp thiết kế cơ sở dữ liệu của mình. Có thể bạn vẫn đang làm hoặc bạn sẽ làm một số trong tương lai. Chúng tôi không thể quay ngược thời gian và giúp bạn hoàn tác các lỗi của mình, nhưng chúng tôi có thể giúp bạn tránh khỏi một số vấn đề đau đầu trong tương lai (hoặc hiện tại).

Đọc bài viết này có thể giúp bạn tiết kiệm nhiều giờ để khắc phục các sự cố về thiết kế và mã, vì vậy chúng ta hãy đi sâu vào. Tôi đã chia danh sách các lỗi thành hai nhóm chính:những lỗi không thuộc về kỹ thuật trong tự nhiên và những thứ nghiêm ngặt về kỹ thuật . Cả hai nhóm này đều là một phần quan trọng của thiết kế cơ sở dữ liệu.

Rõ ràng, nếu bạn không có kỹ năng kỹ thuật, bạn sẽ không biết cách làm điều gì đó. Không có gì ngạc nhiên khi thấy những lỗi này trong danh sách. Nhưng kỹ năng phi kỹ thuật? Mọi người có thể quên chúng, nhưng những kỹ năng này cũng là một phần rất quan trọng trong quá trình thiết kế. Chúng tăng thêm giá trị cho mã của bạn và chúng liên hệ công nghệ với vấn đề trong thế giới thực mà bạn cần giải quyết.

Vì vậy, trước tiên hãy bắt đầu với các vấn đề không liên quan đến kỹ thuật, sau đó chuyển sang các vấn đề kỹ thuật.

Lỗi thiết kế cơ sở dữ liệu phi kỹ thuật

# 1 Lập kế hoạch kém

Đây chắc chắn là một vấn đề không liên quan đến kỹ thuật, nhưng nó là một vấn đề chính và phổ biến. Tất cả chúng ta đều rất hào hứng khi một dự án mới bắt đầu và khi bắt đầu thực hiện, mọi thứ đều tuyệt vời. Khi bắt đầu, dự án vẫn là một trang trống và bạn và khách hàng của bạn rất vui khi bắt đầu làm việc gì đó sẽ tạo ra một tương lai tốt đẹp hơn cho cả hai bạn. Tất cả đều tuyệt vời, và một tương lai tuyệt vời có lẽ sẽ là kết quả cuối cùng. Tuy nhiên, chúng tôi cần phải tập trung. Đây là một phần của dự án mà chúng tôi có thể mắc phải những sai lầm quan trọng.

Trước khi ngồi vẽ mô hình dữ liệu, bạn cần chắc chắn rằng:

• Bạn hoàn toàn biết khách hàng của mình làm gì (tức là kế hoạch kinh doanh của họ liên quan đến dự án này và cả bức tranh tổng thể của họ) và những gì họ muốn dự án này đạt được trong hiện tại và trong tương lai.
• Bạn hiểu quy trình kinh doanh và nếu cần hoặc khi cần, bạn sẵn sàng đưa ra các đề xuất để đơn giản hóa và cải thiện quy trình (ví dụ:tăng hiệu quả và thu nhập, giảm chi phí và giờ làm việc, v.v.).
• Bạn hiểu luồng dữ liệu trong công ty của khách hàng. Lý tưởng nhất là bạn phải biết mọi chi tiết:ai làm việc với dữ liệu, ai thực hiện thay đổi, báo cáo nào là cần thiết, khi nào và tại sao tất cả những điều này xảy ra.
• Bạn có thể sử dụng ngôn ngữ / thuật ngữ mà khách hàng của bạn sử dụng. Mặc dù bạn có thể có hoặc không phải là chuyên gia trong lĩnh vực của họ, nhưng khách hàng của bạn chắc chắn là như vậy. Yêu cầu họ giải thích những gì bạn không hiểu. Và khi bạn giải thích các chi tiết kỹ thuật cho khách hàng, hãy sử dụng ngôn ngữ và thuật ngữ mà họ hiểu.
• Bạn biết mình sẽ sử dụng công nghệ nào, từ công cụ cơ sở dữ liệu và ngôn ngữ lập trình đến các công cụ khác. Những gì bạn quyết định sử dụng có liên quan mật thiết đến vấn đề bạn sẽ giải quyết, nhưng điều quan trọng là phải bao gồm sở thích của khách hàng và cơ sở hạ tầng CNTT hiện tại của họ.

Trong giai đoạn lập kế hoạch, bạn sẽ nhận được câu trả lời cho những câu hỏi sau:

• Bảng nào sẽ là bảng trung tâm trong mô hình của bạn? Bạn có thể sẽ có một vài bảng trong số đó, trong khi các bảng khác sẽ là một số bảng thông thường (ví dụ:user_account, role). Đừng quên về từ điển và mối quan hệ giữa các bảng.
• Những tên nào sẽ được sử dụng cho các bảng trong mô hình? Hãy nhớ giữ thuật ngữ tương tự với bất cứ điều gì khách hàng hiện đang sử dụng.
• Những quy tắc nào sẽ áp dụng khi đặt tên bảng và các đối tượng khác? (Xem Điểm 4 về quy ước đặt tên.)
• Toàn bộ dự án sẽ mất bao lâu? Điều này rất quan trọng đối với cả lịch trình của bạn và dòng thời gian của khách hàng.

Chỉ khi bạn có tất cả những câu trả lời này, bạn mới sẵn sàng chia sẻ giải pháp ban đầu cho vấn đề. Giải pháp đó không cần phải là một ứng dụng hoàn chỉnh - có thể là một tài liệu ngắn hoặc thậm chí một vài câu bằng ngôn ngữ kinh doanh của khách hàng.

Lập kế hoạch tốt không phải là cụ thể cho mô hình dữ liệu; nó có thể áp dụng cho hầu hết mọi dự án CNTT (và phi CNTT). Bỏ qua chỉ là một lựa chọn nếu 1) bạn có một dự án thực sự nhỏ; 2) các nhiệm vụ và mục tiêu rõ ràng, và 3) bạn thực sự vội vàng. Một ví dụ lịch sử là các kỹ sư phóng Sputnik 1 đưa ra hướng dẫn bằng lời nói cho các kỹ thuật viên đang lắp ráp nó. Dự án đang diễn ra gấp rút vì có thông tin rằng Hoa Kỳ đang có kế hoạch phóng vệ tinh của riêng họ sớm - nhưng tôi đoán bạn sẽ không vội vàng như vậy.

# 2 Giao tiếp không đầy đủ với khách hàng và nhà phát triển

Khi bạn bắt đầu quá trình thiết kế cơ sở dữ liệu, có thể bạn sẽ hiểu hầu hết các yêu cầu chính. Một số rất phổ biến bất kể lĩnh vực kinh doanh nào, ví dụ:vai trò và trạng thái của người dùng. Mặt khác, một số bảng trong mô hình của bạn sẽ khá cụ thể. Ví dụ:nếu bạn đang xây dựng mô hình cho một công ty taxi, bạn sẽ có các bảng cho xe cộ, tài xế, khách hàng, v.v.

Tuy nhiên, không phải mọi thứ đều rõ ràng khi bắt đầu một dự án. Bạn có thể hiểu sai một số yêu cầu, khách hàng có thể thêm một số chức năng mới, bạn sẽ thấy điều gì đó có thể được thực hiện theo cách khác, quy trình có thể thay đổi, v.v. Tất cả những điều này gây ra những thay đổi trong mô hình. Hầu hết các thay đổi yêu cầu thêm bảng mới, nhưng đôi khi bạn sẽ xóa hoặc sửa đổi bảng. Nếu bạn đã bắt đầu viết mã sử dụng các bảng này, bạn cũng cần phải viết lại mã đó.

Để giảm thời gian dành cho những thay đổi không mong muốn, bạn nên:

• Nói chuyện với các nhà phát triển và khách hàng và đừng ngại đặt những câu hỏi quan trọng về kinh doanh. Khi bạn nghĩ rằng mình đã sẵn sàng để bắt đầu, hãy tự hỏi mình Tình huống X có được đưa vào cơ sở dữ liệu của chúng tôi không? Khách hàng hiện đang làm Y theo cách này; chúng ta có mong đợi sự thay đổi trong tương lai gần không? Khi chúng tôi tự tin rằng mô hình của mình có khả năng lưu trữ mọi thứ chúng tôi cần theo đúng cách, chúng tôi có thể bắt đầu viết mã.
• Nếu bạn phải đối mặt với một sự thay đổi lớn trong thiết kế của mình và bạn đã viết nhiều mã, bạn không nên cố gắng sửa chữa nhanh chóng. Hãy làm điều đó như lẽ ra phải làm, bất kể hoàn cảnh hiện tại như thế nào. Một bản sửa lỗi nhanh có thể tiết kiệm thời gian ngay bây giờ và có thể sẽ hoạt động tốt trong một thời gian, nhưng nó có thể biến thành cơn ác mộng thực sự sau này.
• Nếu bạn cho rằng điều gì đó hiện tại ổn nhưng có thể trở thành vấn đề sau này, đừng bỏ qua nó. Phân tích khu vực đó và thực hiện các thay đổi nếu chúng sẽ cải thiện chất lượng và hiệu suất của hệ thống. Sẽ mất một khoảng thời gian nhưng bạn sẽ mang đến một sản phẩm tốt hơn và ngủ ngon hơn nhiều.

Nếu bạn cố gắng tránh thực hiện các thay đổi trong mô hình dữ liệu của mình khi thấy sự cố tiềm ẩn - hoặc nếu bạn chọn cách khắc phục nhanh thay vì thực hiện đúng cách - thì sớm muộn gì bạn cũng sẽ phải trả cho điều đó.

Ngoài ra, hãy giữ liên lạc với khách hàng của bạn và các nhà phát triển trong suốt dự án. Luôn kiểm tra và xem liệu có bất kỳ thay đổi nào được thực hiện kể từ cuộc thảo luận cuối cùng của bạn hay không.

# 3 Tài liệu Kém hoặc Thiếu

Đối với hầu hết chúng ta, tài liệu hướng dẫn có ở phần cuối của dự án. Nếu chúng tôi được tổ chức tốt, chúng tôi có thể đã ghi lại mọi thứ trong suốt quá trình và chúng tôi sẽ chỉ cần tóm tắt mọi thứ. Nhưng thành thật mà nói, điều đó thường không xảy ra. Việc viết tài liệu diễn ra ngay trước khi dự án kết thúc - và ngay sau khi chúng tôi đã hoàn thành về mặt tinh thần với mô hình dữ liệu đó!

Cái giá phải trả cho một dự án được ghi chép kém có thể khá cao, cao hơn vài lần so với cái giá mà chúng ta phải trả để ghi lại mọi thứ một cách chính xác. Hãy tưởng tượng bạn sẽ tìm thấy một lỗi vài tháng sau khi bạn đóng dự án. Bởi vì bạn không ghi lại đúng cách, bạn không biết bắt đầu từ đâu.

Khi bạn đang làm việc, đừng quên viết nhận xét. Giải thích mọi thứ cần giải thích bổ sung và về cơ bản, hãy viết ra mọi thứ bạn nghĩ sẽ hữu ích vào một ngày nào đó. Bạn không bao giờ biết nếu hoặc khi nào bạn cần thông tin bổ sung đó.

Sai lầm trong thiết kế cơ sở dữ liệu kỹ thuật

# 4 Không sử dụng quy ước đặt tên

Bạn không bao giờ biết chắc một dự án sẽ kéo dài bao lâu và liệu bạn có nhiều người làm việc trên mô hình dữ liệu hay không. Có một điểm khi bạn thực sự gần đến mô hình dữ liệu, nhưng bạn vẫn chưa bắt đầu thực sự vẽ nó. Đây là lúc bạn nên quyết định cách đặt tên các đối tượng trong mô hình của mình, trong cơ sở dữ liệu và trong ứng dụng chung. Trước khi lập mô hình, bạn nên biết:

• Tên bảng là số ít hay số nhiều?
• Chúng tôi sẽ nhóm các bảng bằng cách sử dụng tên? (Ví dụ:tất cả các bảng liên quan đến máy khách chứa “client_”, tất cả các bảng liên quan đến tác vụ chứa “task_”, v.v.)
• Chúng tôi sẽ sử dụng chữ hoa và chữ thường hay chỉ viết thường?
• Chúng tôi sẽ sử dụng tên nào cho các cột ID? (Nhiều khả năng nó sẽ là “id”.)
• Chúng tôi sẽ đặt tên cho các khóa ngoại như thế nào? (Rất có thể là “id_” và tên của bảng được tham chiếu.)

So sánh một phần của mô hình không sử dụng quy ước đặt tên với phần tương tự sử dụng quy ước đặt tên, như được minh họa bên dưới:

Ở đây chỉ có một số bảng, nhưng vẫn khá rõ ràng là mô hình nào dễ đọc hơn. Lưu ý rằng:

• Cả hai mô hình đều "hoạt động", vì vậy không có vấn đề gì về mặt kỹ thuật.
• Trong ví dụ về quy ước không đặt tên (ba bảng trên), có một số điều ảnh hưởng đáng kể đến khả năng đọc:sử dụng cả dạng số ít và số nhiều trong tên bảng; các tên khóa chính không được chuẩn hóa (employees_id , id_role ); và các thuộc tính trong các bảng khác nhau có cùng tên (ví dụ:tên xuất hiện trong cả “employee ”Và“ roles ”).

Bây giờ hãy tưởng tượng chúng ta sẽ tạo ra mớ hỗn độn nếu mô hình của chúng ta chứa hàng trăm bảng. Có thể chúng tôi có thể làm việc với một mô hình như vậy (nếu chúng tôi tự tạo ra nó) nhưng chúng tôi sẽ khiến ai đó rất xui xẻo nếu họ phải làm việc trên nó sau chúng tôi.

Để tránh các vấn đề về tên trong tương lai, không sử dụng các từ dành riêng cho SQL, các ký tự đặc biệt hoặc dấu cách trong đó.

Vì vậy, trước khi bắt đầu tạo bất kỳ tên nào, hãy tạo một tài liệu đơn giản (có thể chỉ dài vài trang) mô tả quy ước đặt tên mà bạn đã sử dụng. Điều này sẽ làm tăng khả năng đọc của toàn bộ mô hình và đơn giản hóa công việc trong tương lai.

Bạn có thể đọc thêm về các quy ước đặt tên trong hai bài viết này:

• Đặt tên cho các quy ước trong mô hình cơ sở dữ liệu
• Một cái nhìn logic khác thường về quy ước đặt tên máy chủ SQL

# 5 Vấn đề về Chuẩn hóa

Chuẩn hóa là một phần thiết yếu của thiết kế cơ sở dữ liệu. Mọi cơ sở dữ liệu phải được chuẩn hóa thành ít nhất 3NF (khóa chính được xác định, các cột là nguyên tử và không có nhóm lặp lại, phụ thuộc một phần hoặc phụ thuộc bắc cầu). Điều này làm giảm sự trùng lặp dữ liệu và đảm bảo tính toàn vẹn của tham chiếu.

Bạn có thể đọc thêm về chuẩn hóa trong bài viết này. Nói tóm lại, bất cứ khi nào chúng ta nói về mô hình cơ sở dữ liệu quan hệ, chúng ta đang nói về cơ sở dữ liệu chuẩn hóa. Nếu cơ sở dữ liệu không được chuẩn hóa, chúng tôi sẽ gặp phải một loạt các vấn đề liên quan đến tính toàn vẹn của dữ liệu.

Trong một số trường hợp, chúng tôi có thể muốn chuẩn hóa cơ sở dữ liệu của mình. Nếu bạn làm điều này, có một lý do thực sự chính đáng. Bạn có thể đọc thêm về chuẩn hóa cơ sở dữ liệu tại đây.

# 6 Sử dụng Mô hình Thực thể-Thuộc tính-Giá trị (EAV)

EAV là viết tắt của thực thể-thuộc tính-giá trị. Cấu trúc này có thể được sử dụng để lưu trữ dữ liệu bổ sung về bất kỳ thứ gì trong mô hình của chúng tôi. Hãy xem một ví dụ.

Giả sử rằng chúng ta muốn lưu trữ một số thuộc tính khách hàng bổ sung. “customer Bảng "là thực thể của chúng tôi," attribute Bảng ”rõ ràng là thuộc tính của chúng tôi và“ attribute_value ”Chứa giá trị của thuộc tính đó cho khách hàng đó.

Đầu tiên, chúng tôi sẽ thêm một từ điển với danh sách tất cả các thuộc tính khả thi mà chúng tôi có thể gán cho khách hàng. Đây là “attribute " bàn. Nó có thể chứa các thuộc tính như “giá trị khách hàng”, “chi tiết liên hệ”, “thông tin bổ sung”, v.v. “customer_attribute ”Bảng chứa danh sách tất cả các thuộc tính, với các giá trị, cho từng khách hàng. Đối với mỗi khách hàng, chúng tôi sẽ chỉ có bản ghi cho các thuộc tính mà họ có và chúng tôi sẽ lưu trữ “attribute_value ”Cho thuộc tính đó.

Điều này có vẻ thực sự tuyệt vời. Nó sẽ cho phép chúng tôi thêm các thuộc tính mới một cách dễ dàng (vì chúng tôi thêm chúng dưới dạng giá trị trong “customer_attribute " bàn). Do đó, chúng tôi sẽ tránh thực hiện các thay đổi trong cơ sở dữ liệu. Gần như không thể tin nổi.

Và nó là quá tốt. Mặc dù mô hình sẽ lưu trữ dữ liệu mà chúng ta cần, nhưng làm việc với dữ liệu đó phức tạp hơn nhiều. Và điều đó bao gồm hầu hết mọi thứ, từ viết các truy vấn SELECT đơn giản đến nhận tất cả các giá trị liên quan đến khách hàng đến chèn, cập nhật hoặc xóa giá trị.

Tóm lại, chúng ta nên tránh cấu trúc EAV. Nếu bạn phải sử dụng nó, chỉ sử dụng nó khi bạn chắc chắn 100% rằng nó thực sự cần thiết.

# 7 Sử dụng GUID / UUID làm Khóa chính

GUID (Số nhận dạng duy nhất trên toàn cầu) là một số 128 bit được tạo theo các quy tắc được xác định trong RFC 4122. Chúng đôi khi còn được gọi là UUID (Số nhận dạng duy nhất trên toàn cầu). Ưu điểm chính của GUID là nó là duy nhất; khả năng bạn đánh cùng một GUID hai lần thực sự khó xảy ra. Do đó, GUID có vẻ như là một ứng cử viên sáng giá cho cột khóa chính. Nhưng đó không phải là trường hợp.

Quy tắc chung cho khóa chính là chúng tôi sử dụng cột số nguyên với thuộc tính autoincrement được đặt thành “yes”. Thao tác này sẽ thêm dữ liệu theo thứ tự tuần tự vào khóa chính và mang lại hiệu suất tối ưu. Nếu không có khóa tuần tự hoặc dấu thời gian, không có cách nào để biết dữ liệu nào đã được chèn trước. Vấn đề này cũng phát sinh khi chúng tôi sử dụng các giá trị DUY NHẤT trong thế giới thực (ví dụ:ID VAT). Mặc dù chúng giữ các giá trị DUY NHẤT, nhưng chúng không tạo khóa chính tốt. Thay vào đó, hãy sử dụng chúng làm khóa thay thế.

Một lưu ý bổ sung: Tôi thích sử dụng các thuộc tính số nguyên được tạo tự động một cột làm khóa chính. Đó chắc chắn là phương pháp hay nhất. Tôi khuyên bạn nên tránh sử dụng khóa chính tổng hợp.

# 8 Lập chỉ mục không đủ

• Chỉ mục cơ sở dữ liệu là gì?
• Tất cả về chỉ mục:Kiến thức rất cơ bản
• Tất cả Giới thiệu về Chỉ mục Phần 2:Cấu trúc và Hiệu suất Chỉ mục MySQL

Phiên bản ngắn gọn là tôi khuyên bạn nên thêm một chỉ mục vào bất cứ nơi nào bạn muốn nó sẽ cần thiết. Bạn cũng có thể thêm chúng sau khi cơ sở dữ liệu được sản xuất nếu bạn thấy rằng việc thêm chỉ mục vào một vị trí nhất định sẽ cải thiện hiệu suất.

# 9 Dữ liệu Dự phòng

Dữ liệu thừa thường nên được tránh trong bất kỳ mô hình nào. Nó không chỉ chiếm thêm dung lượng đĩa mà còn làm tăng đáng kể nguy cơ xảy ra các vấn đề về tính toàn vẹn của dữ liệu. Nếu phải thừa một thứ gì đó, chúng ta nên lưu ý rằng dữ liệu gốc và “bản sao” luôn ở trạng thái nhất quán. Trên thực tế, có một số trường hợp mong muốn dữ liệu dư thừa:

• Trong một số trường hợp, chúng tôi phải chỉ định mức độ ưu tiên cho một hành động nhất định - và để điều này xảy ra, chúng tôi phải thực hiện các phép tính phức tạp. Các phép tính này có thể sử dụng nhiều bảng và tiêu tốn nhiều tài nguyên. Trong những trường hợp như vậy, sẽ là khôn ngoan nếu thực hiện các phép tính này trong giờ nghỉ (do đó tránh được các vấn đề về hiệu suất trong giờ làm việc). Nếu chúng ta làm theo cách này, chúng ta có thể lưu trữ giá trị đã tính đó và sử dụng nó sau này mà không cần phải tính toán lại. Tất nhiên, giá trị là dư thừa; tuy nhiên, những gì chúng ta thu được về hiệu suất nhiều hơn đáng kể so với những gì chúng ta mất (một số dung lượng ổ cứng).
• Chúng tôi cũng có thể lưu trữ một tập hợp nhỏ dữ liệu báo cáo bên trong cơ sở dữ liệu. Ví dụ:vào cuối ngày, chúng tôi sẽ lưu trữ số lượng cuộc gọi chúng tôi đã thực hiện trong ngày hôm đó, số lần bán hàng thành công, v.v. Chỉ nên lưu trữ dữ liệu báo cáo theo cách này nếu chúng tôi cần sử dụng thường xuyên. Một lần nữa, chúng tôi sẽ mất một ít dung lượng ổ cứng, nhưng chúng tôi sẽ tránh tính toán lại dữ liệu hoặc kết nối với cơ sở dữ liệu báo cáo (nếu có).

Trong hầu hết các trường hợp, chúng ta không nên sử dụng dữ liệu thừa vì:

• Việc lưu trữ cùng một dữ liệu nhiều lần trong cơ sở dữ liệu có thể ảnh hưởng đến tính toàn vẹn của dữ liệu. Nếu bạn lưu tên khách hàng ở hai nơi khác nhau, bạn nên thực hiện bất kỳ thay đổi nào (chèn / cập nhật / xóa) cho cả hai nơi cùng một lúc. Điều này cũng làm phức tạp thêm mã bạn cần, ngay cả đối với những thao tác đơn giản nhất.
• Mặc dù chúng tôi có thể lưu trữ một số con số tổng hợp trong cơ sở dữ liệu hoạt động của mình, nhưng chúng tôi chỉ nên thực hiện việc này khi chúng tôi thực sự cần. Cơ sở dữ liệu hoạt động không có nghĩa là để lưu trữ dữ liệu báo cáo, và việc trộn hai dữ liệu này nói chung là một cách làm không tốt. Bất kỳ ai tạo báo cáo sẽ phải sử dụng các tài nguyên giống như những người dùng làm các nhiệm vụ vận hành; các truy vấn báo cáo thường phức tạp hơn và có thể ảnh hưởng đến hiệu suất. Do đó, bạn nên tách biệt cơ sở dữ liệu hoạt động và cơ sở dữ liệu báo cáo của mình.

Bây giờ đến lượt bạn cân nhắc

Tôi hy vọng rằng việc đọc bài viết này đã cung cấp cho bạn một số hiểu biết mới và sẽ khuyến khích bạn làm theo các phương pháp hay nhất về lập mô hình dữ liệu. Chúng sẽ giúp bạn tiết kiệm thời gian!

Bạn đã trải qua bất kỳ vấn đề nào được đề cập trong bài viết này chưa? Bạn có nghĩ rằng chúng tôi đã bỏ lỡ điều gì đó quan trọng không? Hay bạn nghĩ chúng ta nên xóa thứ gì đó khỏi danh sách của mình? Vui lòng cho chúng tôi biết trong phần bình luận bên dưới.