Những sai lầm thường gặp trong thiết kế cơ sở dữ liệu

Cho dù bạn đang làm việc với một cơ sở dữ liệu chứa hàng trăm bản ghi hoặc hàng triệu bản ghi, thiết kế cơ sở dữ liệu thích hợp luôn quan trọng. Không chỉ nó sẽ làm cho việc lấy thông tin dễ dàng hơn nhiều, nó cũng sẽ đơn giản hóa việc mở rộng cơ sở dữ liệu trong tương lai. Thật không may, thật dễ dàng rơi vào một vài cái bẫy có thể khiến mọi thứ trở nên khó khăn trong tương lai.

Có toàn bộ sách được viết về chủ đề bình thường hóa một cơ sở dữ liệu, nhưng nếu bạn chỉ đơn giản là tránh những sai lầm phổ biến này, bạn sẽ đi đúng hướng để thiết kế cơ sở dữ liệu tốt.

Lỗi cơ sở dữ liệu # 1: Các trường lặp lại trong bảng

Nguyên tắc cơ bản của ngón tay cái để thiết kế cơ sở dữ liệu tốt là nhận biết dữ liệu lặp lại và đặt các cột lặp lại đó trong bảng của riêng chúng. Các trường lặp lại trong một bảng là phổ biến cho những người đến từ thế giới của bảng tính, nhưng trong khi các bảng tính có xu hướng phẳng bằng thiết kế, cơ sở dữ liệu phải có quan hệ. Nó giống như đi từ 2D đến 3D.

May mắn thay, các trường lặp lại thường dễ phát hiện. Chỉ cần nhìn vào bảng này:

OrderID Sản phẩm1 Product2 Sản phẩm 3
1 Gấu bông Kẹo dẻo
2 Kẹo dẻo

Điều gì sẽ xảy ra khi một đơn đặt hàng chứa bốn sản phẩm? Chúng tôi sẽ cần thêm một trường khác vào bảng để hỗ trợ nhiều hơn ba sản phẩm. Và nếu chúng tôi đã tạo ứng dụng khách quanh bàn để giúp chúng tôi nhập dữ liệu, chúng tôi có thể cần sửa đổi dữ liệu đó với trường sản phẩm mới. Và làm thế nào để chúng tôi tìm thấy tất cả các đơn đặt hàng với Jellybeans theo thứ tự? Chúng tôi sẽ buộc phải truy vấn mọi trường sản phẩm trong bảng bằng câu lệnh SQL có thể trông giống như: SELECT * FROM Products WHERE Product1 = 'Jelly Beans' HOẶC Product2 = 'Jelly Beans' HOẶC Product3 = 'Jelly Beans'.

Thay vì có một bảng duy nhất kết hợp tất cả thông tin với nhau, chúng ta nên có ba bảng mà mỗi bảng chứa một phần thông tin riêng biệt. Trong ví dụ này, chúng tôi sẽ muốn một bảng Đơn hàng có thông tin về chính đơn đặt hàng đó, một bảng Sản phẩm với tất cả các sản phẩm của chúng tôi và máy tính bảng ProductOrders liên kết các sản phẩm với đơn đặt hàng.

OrderID ID khách hàng Ngày đặt hàng Toàn bộ
1 7 1/24/17 19,99
2 9 1/25/17 24,99
ID sản phẩm Sản phẩm Đếm
1 Gấu bông 1
2 Kẹo dẻo 100
ProductOrderID ID sản phẩm OrderID
101 1 1
102 2 1

Lưu ý cách mỗi bảng có trường ID duy nhất của riêng nó. Đây là khóa chính. Chúng tôi liên kết các bảng bằng cách sử dụng giá trị khóa chính làm khóa ngoại trong bảng khác. Đọc thêm về khóa chính và khóa ngoại.

Lỗi cơ sở dữ liệu # 2: Nhúng bảng vào bảng

Đây là một sai lầm phổ biến khác, nhưng nó không phải luôn luôn nổi bật khá nhiều như các lĩnh vực lặp đi lặp lại. Khi thiết kế cơ sở dữ liệu, bạn muốn đảm bảo tất cả dữ liệu trong một bảng liên quan đến chính nó. Nó giống như trò chơi của đứa trẻ về việc phát hiện ra những gì khác biệt. Nếu bạn có một quả chuối, dâu tây, đào và tivi, TV có thể thuộc về nơi khác.

Dọc theo cùng một dòng, nếu bạn có một bảng người bán hàng, tất cả thông tin trong bảng đó phải liên quan cụ thể đến người bán hàng đó. Bất kỳ thông tin bổ sung nào không phải là duy nhất cho người bán hàng đó có thể thuộc về một nơi khác trong cơ sở dữ liệu của bạn.

SalesID Đầu tiên Cuối cùng Địa chỉ nhà Số điện thoại Văn phòng Số văn phòng
1 Sam Elliot 118 Main St, Austin, TX (215) 555-5858 Trung tâm thành phố Austin (212) 421-2412
2 Alice thợ rèn 504 2nd Street, New York, NY (211) 122-1821 New York (Đông) (211) 855-4541
3 Joe Giáo xứ 428 Aker St, Austin, TX (215) 545-5545 Trung tâm thành phố Austin (212) 421-2412

Trong khi bảng này có thể trông giống như nó là tất cả liên quan đến nhân viên bán hàng cá nhân, nó thực sự có một bảng được nhúng trong bảng. Lưu ý cách Office và OfficeNumber lặp lại với "Austin Downtown". Điều gì sẽ xảy ra nếu số điện thoại văn phòng thay đổi? Bạn sẽ cần cập nhật toàn bộ tập dữ liệu cho một phần thông tin thay đổi, điều này không bao giờ là điều tốt. Các trường này nên được chuyển đến bảng riêng của chúng.

SalesID Đầu tiên Cuối cùng Địa chỉ nhà Số điện thoại OfficeID
1 Sam Elliot 118 Main St, Austin, TX (215) 555-5858 1
2 Alice thợ rèn 504 2nd Street, New York, NY (211) 122-1821 2
3 Joe Giáo xứ 428 Aker St, Austin, TX (215) 545-5545 1
OfficeID Văn phòng Số văn phòng
1 Trung tâm thành phố Austin (212) 421-2412
2 New York (Đông) (211) 855-4541

Kiểu thiết kế này cũng cung cấp cho bạn khả năng thêm thông tin bổ sung vào bảng Office mà không tạo ra một cơn ác mộng về sự lộn xộn trong bảng người bán hàng. Hãy tưởng tượng bao nhiêu công việc nó sẽ chỉ đơn giản là theo dõi các địa chỉ đường phố, thành phố, tiểu bang và mã zip nếu tất cả các thông tin đó là trong bảng người bán hàng!

Lỗi cơ sở dữ liệu số 3: Đưa hai hoặc nhiều mẩu thông tin vào một trường đơn lẻ

Việc nhúng thông tin văn phòng vào bảng người bán hàng không phải là vấn đề duy nhất với cơ sở dữ liệu đó. Trường địa chỉ chứa ba phần thông tin: địa chỉ đường phố, thành phố và tiểu bang. Mỗi trường trong cơ sở dữ liệu chỉ nên chứa một phần thông tin duy nhất. Khi bạn có nhiều mẩu thông tin trong một trường đơn lẻ, nó có thể trở nên khó khăn hơn để truy vấn cơ sở dữ liệu để biết thông tin.

Ví dụ, nếu chúng ta muốn chạy một truy vấn trên tất cả những người bán hàng từ Austin? Chúng tôi sẽ cần phải tìm kiếm trong trường địa chỉ, đó không chỉ là không hiệu quả, nhưng có thể trả về thông tin xấu. Xét cho cùng, chuyện gì xảy ra nếu ai đó sống trên đường Austin ở Portland, Oregon?

Đây là bảng trông như thế nào:

SalesID Đầu tiên Cuối cùng Địa chỉ 1 Địa chỉ 2 Thành phố Tiểu bang Zip Điện thoại
1 Sam Elliot 118 Main St Austin TX 78720 2155555858
2 Alice thợ rèn 504 2nd St Newyork NY 10022 2111221821
3 Joe Giáo xứ 428 Aker St Apt 304 Austin TX 78716 2155455545

Có một vài điều cần lưu ý ở đây. Đầu tiên, "Address1" và "Address2" dường như nằm trong các trường lặp đi lặp lại.

Tuy nhiên, trong trường hợp này, họ đang đề cập đến các phần dữ liệu riêng biệt có liên quan trực tiếp đến người bán hàng chứ không phải là một nhóm dữ liệu lặp đi lặp lại trong bảng riêng của nó.

Ngoài ra, như một lỗi tiền thưởng để tránh, hãy lưu ý cách định dạng cho số điện thoại đã bị tước khỏi bảng. Bạn nên tránh lưu trữ định dạng của các trường khi có thể. Trong trường hợp số điện thoại, có nhiều cách để mọi người viết số điện thoại: 215-555-5858 hoặc (215) 555-5858. Điều này sẽ làm cho việc tìm kiếm một người bán hàng bằng số điện thoại của họ hoặc thực hiện tìm kiếm người bán hàng trong cùng một mã vùng khó khăn hơn.

Lỗi cơ sở dữ liệu số 4: Không sử dụng khóa chính chính xác

Trong hầu hết các trường hợp, bạn sẽ muốn sử dụng số tăng tự động hoặc một số số hoặc chữ số được tạo khác cho khóa chính của bạn. Bạn nên tránh sử dụng bất kỳ thông tin thực tế nào cho khóa chính ngay cả khi có vẻ như nó sẽ tạo một số nhận dạng tốt.

Ví dụ, mỗi chúng ta có số an sinh xã hội riêng của mình, vì vậy việc sử dụng số an sinh xã hội cho cơ sở dữ liệu của nhân viên có vẻ như là một ý tưởng hay. Nhưng trong khi hiếm hoi, có thể ngay cả một số an sinh xã hội để thay đổi, và chúng tôi không bao giờ muốn chìa khóa chính của chúng tôi thay đổi.

Và đó là vấn đề với việc sử dụng thông tin thực tế như một giá trị quan trọng. Nó có thể thay đổi.

Lỗi cơ sở dữ liệu số 5: Không sử dụng Công ước đặt tên

Điều này có thể không giống như một vấn đề lớn khi bạn bắt đầu thiết kế cơ sở dữ liệu của bạn, nhưng một khi bạn nhận được các truy vấn viết đối với cơ sở dữ liệu để lấy thông tin, có một quy ước đặt tên sẽ giúp bạn ghi nhớ tên trường.

Chỉ cần tưởng tượng bao nhiêu khó khăn hơn quá trình đó sẽ được nếu tên được lưu trữ như FirstName, LastName trong một bảng và first_name, last_name trong bảng khác.

Hai quy ước đặt tên phổ biến nhất là viết hoa chữ cái đầu tiên của mỗi từ trong trường hoặc tách các từ bằng dấu gạch dưới. Bạn cũng có thể thấy một số nhà phát triển tận dụng chữ cái đầu tiên của mỗi từ ngoại trừ từ đầu tiên: firstName, lastName.

Bạn cũng sẽ muốn quyết định sử dụng tên bảng số ít hoặc tên bảng số nhiều. Đây có phải là bảng Đơn hàng hoặc bảng Đơn hàng không? Nó là một bảng khách hàng hoặc bảng khách hàng? Một lần nữa, bạn không muốn bị mắc kẹt với một bảng Order và một bảng Customers.

Quy ước đặt tên bạn chọn không quan trọng như quy trình thực sự lựa chọn và gắn bó với quy ước đặt tên.

Lỗi cơ sở dữ liệu số 6: Lập chỉ mục không đúng cách

Lập chỉ mục là một trong những điều khó khăn nhất để có được quyền, đặc biệt là đối với những người mới ở thiết kế cơ sở dữ liệu. Tất cả các khóa chính và khóa ngoài nên được lập chỉ mục. Đây là những gì liên kết bảng với nhau, vì vậy mà không có một chỉ mục, bạn sẽ thấy hiệu suất rất kém ra khỏi cơ sở dữ liệu của bạn.

Nhưng những gì quá thường xuyên bị bỏ lỡ là các lĩnh vực khác. Đây là những trường "WHERE". Nếu bạn thường thu hẹp tìm kiếm của mình bằng cách sử dụng trường trong mệnh đề WHERE, bạn muốn suy nghĩ về việc đặt chỉ mục trên trường đó. Tuy nhiên, bạn không muốn lập chỉ mục quá mức bảng, điều này cũng có thể làm tổn thương hiệu suất.

Làm thế nào để quyết định? Đây là một phần của nghệ thuật thiết kế cơ sở dữ liệu. Không có giới hạn cứng về số lượng chỉ mục bạn nên đặt trên bàn. Chủ yếu, bạn muốn lập chỉ mục bất kỳ trường nào thường được sử dụng trong mệnh đề WHERE. Đọc thêm về lập chỉ mục đúng cơ sở dữ liệu của bạn.