Tất cả chúng ta đều mắc sai lầm và chúng ta đều có thể học hỏi từ những sai lầm của người khác. Trong bài đăng này, chúng tôi sẽ xem xét nhiều tài nguyên trực tuyến để tránh thiết kế cơ sở dữ liệu kém có thể dẫn đến nhiều vấn đề và tốn kém cả thời gian và tiền bạc. Và trong một bài viết sắp tới, chúng tôi sẽ cho bạn biết nơi tìm các mẹo và phương pháp hay nhất.
Các lỗi thiết kế cơ sở dữ liệu và những sai lầm cần tránh
Có rất nhiều tài nguyên trực tuyến để giúp các nhà thiết kế cơ sở dữ liệu tránh các lỗi và sai lầm phổ biến. Rõ ràng, bài viết này không phải là một danh sách đầy đủ của tất cả các bài báo hiện có. Thay vào đó, chúng tôi đã xem xét và nhận xét trên nhiều nguồn khác nhau để bạn có thể tìm thấy nguồn phù hợp nhất với mình.
Khuyến nghị của chúng tôi
Nếu chỉ có một bài báo trong số các tài nguyên này mà bạn định đọc, thì đó phải là ‘Cách thiết kế cơ sở dữ liệu sai lầm khủng khiếp’ của Robert Sheldon
Hãy bắt đầu với blog DATAVERSITY cung cấp một loạt các tài nguyên khá tốt:
Các Lỗi Khóa Chính và Khóa Ngoài Cần Tránh
của Michael Blaha | Blog DATAVERSITY | Ngày 2 tháng 9 năm 2015
Các lỗi thiết kế cơ sở dữ liệu khác - Lẫn lộn với các mối quan hệ giữa nhiều và nhiều
của Michael Blaha | Blog DATAVERSITY | Ngày 30 tháng 9 năm 2015
Các lỗi thiết kế cơ sở dữ liệu khác
của Michael Blaha | Blog DATAVERSITY | Ngày 26 tháng 10 năm 2015
Michael Blaha đã đóng góp một bộ ba bài báo hay. Mỗi bài báo đề cập đến những cạm bẫy khác nhau của mô hình cơ sở dữ liệu và thiết kế vật lý; chủ đề bao gồm các khóa, các mối quan hệ và các lỗi chung. Ngoài ra, có những cuộc thảo luận với Michael về một số điểm. Nếu bạn đang tìm kiếm những cạm bẫy xung quanh chìa khóa và các mối quan hệ, đây sẽ là một nơi tốt để bắt đầu.
Ông Blaha nói rằng “khoảng 20% cơ sở dữ liệu vi phạm các quy tắc về khóa chính”. Ồ! Điều đó có nghĩa là khoảng 20% nhà phát triển cơ sở dữ liệu đã không tạo khóa chính đúng cách. Nếu thống kê này là đúng, thì nó thực sự cho thấy tầm quan trọng của các công cụ mô hình hóa dữ liệu “khuyến khích” hoặc thậm chí yêu cầu người lập mô hình xác định khóa chính.
Ông Blaha cũng chia sẻ kinh nghiệm rằng “khoảng 50% cơ sở dữ liệu” có vấn đề về khóa ngoại (theo kinh nghiệm của ông với các cơ sở dữ liệu cũ mà ông đã nghiên cứu). Anh ấy nhắc chúng tôi tránh liên kết không chính thức giữa các bảng bằng cách nhúng giá trị từ bảng này vào bảng khác thay vì sử dụng khóa ngoại.
Tôi đã thấy vấn đề này nhiều lần. Tôi thừa nhận rằng liên kết không chính thức có thể được yêu cầu bởi chức năng được thực hiện, nhưng nó xảy ra thường xuyên hơn do sự lười biếng đơn giản. Ví dụ:chúng tôi có thể muốn hiển thị id người dùng của một người nào đó đã sửa đổi điều gì đó, vì vậy chúng tôi lưu trữ id người dùng trực tiếp trong bảng. Nhưng điều gì sẽ xảy ra nếu người dùng đó thay đổi id người dùng của mình? Sau đó, liên kết không chính thức này bị phá vỡ. Điều này thường do thiết kế và mô hình hóa kém.
Thiết kế cơ sở dữ liệu của bạn:5 sai lầm hàng đầu cần tránh
của Henrique Netzka | Blog DATAVERSITY | Ngày 2 tháng 11 năm 2015
Tôi hơi thất vọng với bài viết này, vì nó có một vài mục khá cụ thể (lưu trữ giao thức trong CLOB) và một vài mục rất chung chung (hãy nghĩ về bản địa hóa). Nhìn chung, bài viết là tốt, nhưng đây có thực sự là 5 sai lầm hàng đầu cần tránh? Theo ý kiến của tôi, có một số sai lầm phổ biến khác nên được đưa vào danh sách.
Tuy nhiên, trên một lưu ý tích cực, đây là một trong số ít các bài báo đề cập đến toàn cầu hóa và bản địa hóa theo bất kỳ cách nào có ý nghĩa. Tôi làm việc trong một môi trường đa ngôn ngữ và đã thấy một số triển khai bản địa hóa khủng khiếp, vì vậy tôi rất vui khi thấy vấn đề này được đề cập. Cột ngôn ngữ và cột múi giờ có vẻ rõ ràng, nhưng chúng rất hiếm khi xuất hiện trong các mô hình cơ sở dữ liệu.
Nói như vậy, tôi nghĩ sẽ rất thú vị khi tạo ra một mô hình bao gồm các bản dịch có thể được thay đổi bởi người dùng cuối (trái ngược với việc sử dụng các gói tài nguyên). Cách đây một thời gian, tôi đã viết về một mô hình cho cơ sở dữ liệu khảo sát trực tuyến. Ở đây, tôi đã lập mô hình bản dịch đơn giản hóa các câu hỏi và lựa chọn câu trả lời:
Giả sử rằng chúng tôi phải cho phép người dùng cuối duy trì bản dịch, phương pháp ưu tiên sẽ là thêm bảng dịch cho các câu hỏi và câu trả lời:
Tôi cũng đã thêm múi giờ vào user_account để chúng tôi có thể lưu trữ ngày / giờ theo giờ địa phương của người dùng:
7 lỗi thiết kế cơ sở dữ liệu phổ biến
bởi Grzegorz Kaczor | Blog Vertabelo | Ngày 17 tháng 7 năm 2015
Tôi sẽ tự quảng cáo một chút ở đây. Chúng tôi cố gắng thường xuyên đăng các bài viết thú vị và hấp dẫn tại đây.
Bài viết cụ thể này chỉ ra một số lĩnh vực quan trọng cần quan tâm, như đặt tên, lập chỉ mục, cân nhắc khối lượng và đường mòn kiểm tra. Bài báo thậm chí còn đi sâu vào các vấn đề liên quan đến các hệ thống DBM cụ thể, như các hạn chế của Oracle về tên bảng. Tôi thực sự thích những ví dụ rõ ràng đẹp mắt, ngay cả khi chúng minh họa cách các nhà thiết kế mắc lỗi và sai sót.
Rõ ràng là không thể liệt kê mọi lỗi thiết kế và những lỗi được liệt kê có thể không phải là của bạn các lỗi phổ biến nhất. Khi chúng tôi viết về những lỗi thường gặp, đó là những lỗi chúng tôi đã mắc phải hoặc đã tìm thấy trong công việc của người khác mà chúng tôi đang vẽ ra. Một danh sách đầy đủ các lỗi, được xếp hạng theo tần suất, sẽ không thể cho một người biên soạn được. Tuy nhiên, tôi nghĩ rằng bài viết này cung cấp một số hiểu biết hữu ích về những cạm bẫy tiềm ẩn. Đó là một nguồn tài nguyên tốt đẹp về tổng thể.
Trong khi ông Kaczor đưa ra một số điểm thú vị trong bài viết của mình, tôi thấy nhận xét của ông về việc “không xem xét khối lượng hoặc lưu lượng truy cập có thể có” khá thú vị. Đặc biệt, khuyến nghị tách dữ liệu được sử dụng thường xuyên khỏi dữ liệu lịch sử là đặc biệt thích hợp. Đây là một giải pháp mà chúng tôi sử dụng thường xuyên trong các ứng dụng nhắn tin của mình; chúng ta phải có lịch sử tìm kiếm của tất cả các tin nhắn, nhưng các tin nhắn có nhiều khả năng được truy cập là những tin nhắn đã được đăng trong vài ngày qua. Vì vậy, tách dữ liệu "đang hoạt động" hoặc dữ liệu gần đây được truy cập thường xuyên (một khối lượng dữ liệu nhỏ hơn nhiều) khỏi dữ liệu lịch sử lâu dài (khối lượng lớn dữ liệu) nói chung là một kỹ thuật rất tốt.
Các lỗi thiết kế cơ sở dữ liệu phổ biến
bởi Troy Blake | Blog DBA cao cấp | Ngày 11 tháng 7 năm 2015
Bài viết của Troy Blake là một tài nguyên tốt khác, mặc dù tôi có thể đã đổi tên bài viết này là “Các lỗi thiết kế SQL Server thường gặp”.
Ví dụ, chúng tôi có nhận xét:“Các thủ tục được lưu trữ là người bạn tốt nhất của bạn khi nói đến việc sử dụng SQL Server một cách hiệu quả”. Điều đó không sao cả, nhưng đây có phải là lỗi chung phổ biến hay là lỗi cụ thể hơn đối với SQL Server? Tôi sẽ phải chọn điều này là SQL Server cụ thể một chút, vì có những bất lợi khi sử dụng các thủ tục được lưu trữ, như kết thúc với các thủ tục được lưu trữ dành riêng cho nhà cung cấp và do đó nhà cung cấp bị khóa. Vì vậy, tôi không phải là người thích đưa "Không sử dụng các thủ tục được lưu trữ" vào danh sách này.
Tuy nhiên, về mặt tích cực, tôi nghĩ rằng tác giả đã xác định được một số sai lầm rất phổ biến, như lập kế hoạch kém, thiết kế hệ thống kém chất lượng, tài liệu hạn chế, tiêu chuẩn đặt tên yếu và thiếu kiểm tra.
Vì vậy, tôi sẽ phân loại đây là một tài liệu tham khảo rất hữu ích cho những người thực hành SQL Server và một tài liệu tham khảo hữu ích cho những người khác.
Bảy sai lầm khi lập mô hình dữ liệu
bởi Kurt Cagle | LinkedIn | Ngày 12 tháng 6 năm 2015
Tôi thực sự thích thú khi đọc danh sách các lỗi lập mô hình cơ sở dữ liệu của ông Cagle. Đây là từ quan điểm của kiến trúc sư cơ sở dữ liệu về mọi thứ; anh ấy xác định rõ ràng những sai lầm khi lập mô hình cấp cao hơn cần tránh. Với chế độ xem hình ảnh lớn hơn này, bạn có thể loại bỏ một mớ hỗn độn về mô hình tiềm năng.
Bạn có thể tìm thấy một số kiểu được đề cập trong bài viết ở những nơi khác, nhưng một vài kiểu trong số này là duy nhất:trừu tượng quá sớm hoặc trộn lẫn các mô hình khái niệm, lôgic và vật lý. Những điều này không thường được các tác giả khác đề cập đến, có lẽ vì họ đang tập trung vào quá trình mô hình hóa dữ liệu hơn là chế độ xem hệ thống lớn hơn.
Cụ thể, ví dụ về “Nhận quá sớm quá trừu tượng” mô tả một quy trình suy nghĩ thú vị là tạo ra một số “câu chuyện” mẫu và kiểm tra mối quan hệ nào là quan trọng trong lĩnh vực này. Điều này tập trung suy nghĩ vào các mối quan hệ giữa các đối tượng được mô hình hóa. Nó dẫn đến các câu hỏi như các mối quan hệ quan trọng trong miền này là gì ?
Dựa trên sự hiểu biết này, chúng tôi tạo ra mô hình xoay quanh các mối quan hệ thay vì bắt đầu từ các mục miền riêng lẻ và xây dựng các mối quan hệ trên chúng. Mặc dù nhiều người trong chúng ta có thể sử dụng cách tiếp cận này, nhưng trong số các nguồn này không có tác giả nào khác nhận xét về nó. Tôi thấy mô tả này và các ví dụ khá thú vị.
Cách thiết kế cơ sở dữ liệu sai kinh khủng
của Robert Sheldon | Nói chuyện đơn giản | Ngày 6 tháng 3 năm 2015
Nếu chỉ có một bài báo trong số các tài nguyên này mà bạn định đọc, thì đó phải là bài viết này của Robert Sheldon
Điều tôi thực sự thích ở bài viết này là đối với mỗi lỗi được đề cập đều có những lời khuyên về cách làm đúng. Hầu hết những điều này tập trung vào việc tránh thất bại hơn là sửa chữa nó, nhưng tôi vẫn nghĩ rằng chúng rất hữu ích. Có rất ít lý thuyết ở đây; chủ yếu là câu trả lời thẳng về việc tránh những sai lầm trong khi lập mô hình dữ liệu. Có một vài điểm SQL Server cụ thể, nhưng chủ yếu là SQL Server được sử dụng để cung cấp các ví dụ về cách tránh lỗi hoặc cách khắc phục sự cố.
Phạm vi của bài viết cũng khá rộng:nó bao gồm việc lơ là lập kế hoạch, không quan tâm đến tài liệu, sử dụng các quy ước đặt tên tệ hại, gặp vấn đề trong quá trình chuẩn hóa (quá nhiều hoặc quá ít), lỗi về khóa và ràng buộc, lập chỉ mục không đúng cách và hoạt động thử nghiệm không đầy đủ.
Đặc biệt, tôi thích lời khuyên thiết thực liên quan đến tính toàn vẹn dữ liệu - khi nào sử dụng các ràng buộc kiểm tra và khi nào xác định khóa ngoại. Ngoài ra, ông Sheldon cũng mô tả tình huống khi các đội trì hoãn ứng dụng để thực thi tính liêm chính. Ông ấy rất thẳng thắn khi nói rằng một cơ sở dữ liệu có thể được truy cập theo nhiều cách và bằng nhiều ứng dụng. Ông kết luận rằng “dữ liệu nên được bảo vệ tại nơi nó cư trú:trong cơ sở dữ liệu”. Điều này đúng đến mức nó có thể được lặp lại với các nhóm phát triển và người quản lý để giải thích tầm quan trọng của việc thực hiện kiểm tra tính toàn vẹn trong mô hình dữ liệu.
Đây là loại bài viết của tôi, và bạn có thể nói rằng những người khác đồng ý dựa trên nhiều bình luận tán thành nó. Vì vậy, điểm cao nhất ở đây; nó là một nguồn tài nguyên rất có giá trị.
Mười lỗi thiết kế cơ sở dữ liệu phổ biến
của Louis Davidson | Nói chuyện đơn giản | Ngày 26 tháng 2 năm 2007
Tôi thấy bài viết này khá hay, vì nó đề cập đến rất nhiều lỗi thiết kế phổ biến. Có những phép loại suy có ý nghĩa, ví dụ, mô hình và thậm chí một số câu trích dẫn cổ điển từ William Shakespeare và J.R.R. Tolkien.
Một số lỗi đã được giải thích chi tiết hơn những lỗi khác, với các ví dụ dài và đoạn trích SQL mà tôi thấy hơi rườm rà. Nhưng đó là vấn đề của thị hiếu.
Một lần nữa, chúng tôi có một vài chủ đề dành riêng cho SQL Server. Ví dụ, quan điểm của việc không sử dụng Thủ tục lưu trữ để truy cập dữ liệu là tốt cho SQL, nhưng SP không phải lúc nào cũng là một ý tưởng hay khi mục tiêu là hỗ trợ trên nhiều DBMS. Ngoài ra, chúng tôi được cảnh báo không nên cố gắng mã hóa các đối tượng T-SQL chung chung. Vì tôi hiếm khi làm việc với SQL Server hoặc Sybase nên tôi không thấy mẹo này có liên quan.
Danh sách này khá giống với Robert Sheldon’s, nhưng nếu bạn chủ yếu làm việc trên SQL Server, thì bạn sẽ tìm thấy một vài thông tin bổ sung.
Năm lỗi thiết kế cơ sở dữ liệu đơn giản mà bạn nên tránh
bởi Anith Sen Larson | Nói chuyện đơn giản | Ngày 16 tháng 10 năm 2009
Bài viết này đưa ra một số ví dụ có ý nghĩa cho từng lỗi thiết kế đơn giản mà nó bao gồm. Mặt khác, nó khá tập trung vào các loại lỗi tương tự:bảng tra cứu thông thường, bảng thực thể-thuộc tính-giá trị và phân tách thuộc tính.
Các quan sát là tốt, và bài báo thậm chí có tài liệu tham khảo, có xu hướng hiếm. Tuy nhiên, tôi vẫn muốn thấy các lỗi thiết kế cơ sở dữ liệu chung hơn. Những lỗi này có vẻ khá cụ thể, nhưng, như tôi đã viết, những lỗi chúng tôi viết về thường là những lỗi mà chúng tôi có kinh nghiệm cá nhân.
Một mục mà tôi thích là quy tắc ngón tay cái cụ thể để quyết định khi nào sử dụng ràng buộc kiểm tra so với một bảng riêng biệt có ràng buộc khóa ngoại. Một số tác giả đưa ra các khuyến nghị tương tự, nhưng ông Larson chia chúng thành “phải”, “cân nhắc” và “trường hợp mạnh mẽ” - với việc thừa nhận rằng “thiết kế là sự kết hợp giữa nghệ thuật và khoa học và do đó nó liên quan đến sự đánh đổi”. Tôi thấy điều này rất đúng.
Mười lỗi thiết kế cơ sở dữ liệu vật lý phổ biến nhất
bởi Craig Mullins | Dữ liệu và Công nghệ Ngày nay | Ngày 5 tháng 8 năm 2013
Như tên gọi của nó, “Mười sai lầm thiết kế cơ sở dữ liệu vật lý phổ biến nhất” hơi thiên về thiết kế vật lý hơn là thiết kế logic và khái niệm. Không có sai lầm nào mà tác giả Craig Mullins đề cập thực sự nổi bật hoặc độc đáo, vì vậy tôi muốn giới thiệu thông tin này cho những người làm việc về phía DBA vật lý.
Ngoài ra, phần mô tả hơi ngắn nên đôi khi khó hiểu tại sao một sai sót cụ thể lại gây ra vấn đề. Vốn dĩ không có gì sai với các mô tả ngắn, nhưng chúng không khiến bạn phải suy nghĩ nhiều. Và không có ví dụ nào được trình bày.
Có một điểm thú vị được nêu ra liên quan đến việc không chia sẻ được dữ liệu. Điểm này thỉnh thoảng được đề cập trong các bài báo khác, nhưng không phải là một lỗi thiết kế. Tuy nhiên, tôi thấy vấn đề này xảy ra khá thường xuyên khi cơ sở dữ liệu được “tạo lại” dựa trên các yêu cầu rất giống nhau, nhưng bởi một nhóm mới hoặc cho một sản phẩm mới
.Điều thường xảy ra là sau này nhóm sản phẩm nhận ra rằng họ muốn sử dụng dữ liệu đã có trong “cha đẻ” của cơ sở dữ liệu hiện tại của họ. Tuy nhiên, trên thực tế, lẽ ra họ phải nâng cao bố mẹ hơn là tạo ra con cái mới. Các ứng dụng nhằm mục đích chia sẻ dữ liệu; thiết kế tốt có thể cho phép cơ sở dữ liệu được sử dụng lại thường xuyên hơn.
Bạn có mắc phải 5 lỗi thiết kế cơ sở dữ liệu này không?
của Thomas Larock | Thomas Larock’s blog | Ngày 2 tháng 1 năm 2012
Bạn có thể tìm thấy một vài điểm thú vị khi trả lời câu hỏi của Thomas Larock:Bạn có mắc phải 5 sai lầm khi thiết kế cơ sở dữ liệu này không?
Bài viết này hơi chú trọng đến các khóa (khóa ngoại, khóa thay thế và khóa được tạo). Tuy nhiên, nó có một điểm quan trọng:không nên cho rằng các tính năng của DBMS là giống nhau trên tất cả các hệ thống. Tôi nghĩ đây là một điểm rất tốt. Đây cũng là một điều không được tìm thấy trong hầu hết các bài báo khác, có lẽ vì nhiều tác giả tập trung vào và chủ yếu làm việc với một DBMS duy nhất.
Thiết kế cơ sở dữ liệu:7 điều bạn không muốn làm
của Thomas Larock | Thomas Larock’s blog | Ngày 16 tháng 1 năm 2013
Ông Larock đã tái sử dụng một số “5 sai lầm khi thiết kế cơ sở dữ liệu” khi viết “7 điều bạn không muốn làm”, nhưng có những điểm tốt khác ở đây.
Điều thú vị là một số điểm mà ông Larock đưa ra không được tìm thấy trong nhiều nguồn khác. Bạn nhận được một vài nhận xét khá độc đáo, chẳng hạn như "không có kỳ vọng về hiệu suất". Đây là một sai lầm nghiêm trọng và dựa trên kinh nghiệm của tôi, nó xảy ra khá thường xuyên. Ngay cả khi phát triển mã ứng dụng, thường là sau khi mô hình dữ liệu, cơ sở dữ liệu và bản thân ứng dụng đã được tạo ra, mọi người mới bắt đầu nghĩ về các yêu cầu phi chức năng (khi các thử nghiệm phi chức năng phải được tạo) và bắt đầu xác định các kỳ vọng về hiệu suất. .
Ngược lại, có một số điểm mà tôi sẽ không đưa vào danh sách Top Ten của riêng mình, chẳng hạn như "phát triển lớn, đề phòng". Tôi thấy vấn đề nhưng nó không cao trong danh sách của tôi khi tạo mô hình dữ liệu. Không có tính cụ thể cho một hệ thống DBM cụ thể, vì vậy đó là một phần thưởng.
Để kết luận, nhiều điểm trong số này có thể được gói gọn trong điểm:“không hiểu các yêu cầu”, điều này thực sự nằm trong danh sách 10 sai lầm hàng đầu của tôi.
Làm thế nào để tránh 8 lỗi phát triển cơ sở dữ liệu phổ biến
bởi Base36 | Ngày 6 tháng 12 năm 2012
Tôi đã khá thích thú khi đọc bài báo này. Tuy nhiên, tôi hơi thất vọng. Không có nhiều cuộc thảo luận về việc tránh né, và quan điểm của bài báo thực sự có vẻ là “đây là những lỗi cơ sở dữ liệu phổ biến” và “tại sao chúng lại là những sai lầm”; mô tả về cách tránh sai lầm ít nổi bật hơn.
Ngoài ra, một số lỗi trong số 8 lỗi hàng đầu của bài viết thực sự bị tranh chấp. Việc sử dụng sai khóa chính là một ví dụ. Base36 cho chúng ta biết rằng chúng phải được tạo bởi hệ thống chứ không phải dựa trên dữ liệu ứng dụng trong hàng. Mặc dù tôi đồng ý với điều này cho đến thời điểm nào đó, nhưng tôi không bị thuyết phục rằng tất cả PK phải luôn luôn được tạo ra; điều đó hơi quá phân loại.
Mặt khác, sai lầm của "Hard Deletes" rất thú vị và không thường được đề cập ở những nơi khác. Xóa mềm có thể gây ra các vấn đề khác, nhưng đúng là chỉ cần đánh dấu một hàng là không hoạt động sẽ có lợi thế khi bạn đang cố gắng tìm xem dữ liệu đó đã đi đâu trong hệ thống ngày hôm qua. Tìm kiếm thông qua nhật ký giao dịch không phải là ý tưởng của tôi về một cách thú vị để dành một ngày.
Bảy Đại Tội của Thiết kế Cơ sở dữ liệu
bởi Jason Tiret | Tạp chí Hệ thống Doanh nghiệp | Ngày 16 tháng 2 năm 2010
Tôi đã khá hy vọng khi bắt đầu đọc bài báo của Jason Tiret, “Bảy đại tội của thiết kế cơ sở dữ liệu”. Vì vậy, tôi rất vui khi thấy rằng nó không chỉ tái chế những sai lầm được tìm thấy trong nhiều bài báo khác. Ngược lại, nó đưa ra một “tội lỗi” mà tôi chưa tìm thấy trong các danh sách khác:cố gắng thực hiện tất cả thiết kế cơ sở dữ liệu “từ trước” và không cập nhật mô hình sau khi cơ sở dữ liệu được sản xuất, khi các thay đổi được thực hiện đối với cơ sở dữ liệu. (Hoặc, như Jason nói, "Không coi mô hình dữ liệu như một sinh vật sống, thở").
Tôi đã thấy sai lầm này nhiều lần. Hầu hết mọi người chỉ nhận ra lỗi của họ khi họ phải cập nhật một mô hình không còn phù hợp với cơ sở dữ liệu thực tế. Tất nhiên, kết quả là một mô hình vô dụng. Như bài báo nêu rõ, “những thay đổi cần phải tìm đường quay trở lại mô hình.”
Mặt khác, phần lớn các mục trong danh sách của Jason đều khá nổi tiếng. Các mô tả là tốt, nhưng không có nhiều ví dụ. Các ví dụ và chi tiết khác sẽ hữu ích.
Các lỗi thiết kế cơ sở dữ liệu phổ biến nhất
của Brian Prince | eWeek.com | Ngày 19 tháng 3 năm 2008
Bài viết “Những sai lầm phổ biến nhất về thiết kế cơ sở dữ liệu” thực sự là một loạt các trang trình bày từ một bản trình bày. Có một vài suy nghĩ thú vị, nhưng một số vật phẩm độc đáo có lẽ là một chút bí truyền. Tôi ghi nhớ những điểm như “Tìm hiểu RAID” và sự tham gia của các bên liên quan.
Nói chung, tôi sẽ không đưa cái này vào danh sách đọc của bạn trừ khi bạn tập trung vào các vấn đề chung (lập kế hoạch, đặt tên, chuẩn hóa, chỉ mục) và chi tiết vật lý.
10 lỗi thiết kế phổ biến
bởi davidm | SQL Server Blog - SQLTeam.com | Ngày 12 tháng 9 năm 2005
Một số điểm trong “Mười lỗi thiết kế phổ biến” rất thú vị và tương đối mới lạ. Tuy nhiên, một số sai lầm trong số này gây ra khá nhiều tranh cãi, chẳng hạn như “sử dụng NULL” và hủy chuẩn hóa.
Tôi đồng ý rằng việc tạo tất cả các cột dưới dạng nullable là một sai lầm, nhưng việc xác định một cột là nullable có thể được yêu cầu đối với một chức năng kinh doanh cụ thể. Do đó, nó có thể được coi là một sai lầm chung chung không? Tôi nghĩ là không.
Một điểm khác mà tôi gặp vấn đề là khử chuẩn hóa. Đây không phải lúc nào cũng là lỗi thiết kế. Ví dụ:có thể cần phải hủy chuẩn hóa vì lý do hiệu suất.
Bài viết này cũng thiếu nhiều chi tiết và ví dụ. Các cuộc trò chuyện giữa DBA và lập trình viên hoặc người quản lý thật thú vị, nhưng tôi sẽ thích các ví dụ cụ thể hơn và lý giải chi tiết cho những lỗi phổ biến này.
OTLT và EAV:hai lỗi thiết kế lớn mà tất cả những người mới bắt đầu mắc phải
của Tony Andrews | Tony Andrews về Oracle và Cơ sở dữ liệu | Ngày 21 tháng 10 năm 2004
Bài báo của ông Andrews nhắc chúng ta nhớ đến những sai lầm về “Một Bảng Tra cứu Đúng” (OTLT) và Thực thể-Thuộc tính-Giá trị (EAV) đã được đề cập trong các bài viết khác. Một điểm hay về bài thuyết trình này là nó tập trung vào hai sai lầm này, vì vậy các mô tả và ví dụ đều chính xác. Ngoài ra, có thể giải thích lý do tại sao một số nhà thiết kế triển khai OTLT và EAV.
Để nhắc nhở bạn, bảng OTLT thường trông giống như thế này, với các mục nhập từ nhiều miền được đưa vào cùng một bảng:
Như thường lệ, có một cuộc thảo luận xung quanh việc liệu OTLT có phải là một giải pháp khả thi và một mẫu thiết kế tốt hay không. Tôi phải nói rằng tôi đứng về phía nhóm chống OTLT; các bảng này giới thiệu nhiều vấn đề. Chúng ta có thể sử dụng phép loại suy của việc sử dụng một điều tra viên duy nhất để biểu diễn tất cả các giá trị có thể có của tất cả các hằng số có thể có. Tôi chưa bao giờ thấy điều đó cho đến nay.
Các lỗi cơ sở dữ liệu phổ biến
của John Paul Ashenfelter | Tiến sĩ Dobb’s | Ngày 01 tháng 01 năm 2002
Bài báo của ông Ashenfelter liệt kê 15 lỗi cơ sở dữ liệu phổ biến. Thậm chí còn có một số sai sót không thường xuyên được đề cập trong các bài viết khác. Thật không may, các mô tả tương đối ngắn và không có ví dụ. Điểm đáng mừng của bài viết này là danh sách bao gồm rất nhiều cơ sở và có thể được sử dụng như một "danh sách kiểm tra" những sai lầm cần tránh. Mặc dù tôi có thể không phân loại đây là những lỗi cơ sở dữ liệu quan trọng nhất, nhưng chúng chắc chắn là một trong những lỗi phổ biến nhất.
Một lưu ý tích cực, đây là một trong số ít các bài báo đề cập đến sự cần thiết phải xử lý quốc tế hóa các định dạng cho dữ liệu như ngày tháng, đơn vị tiền tệ và địa chỉ. Một ví dụ sẽ rất hay ở đây. Nó có thể đơn giản như “hãy chắc chắn rằng State là một cột có thể nullable; ở nhiều quốc gia, không có tiểu bang nào được liên kết với một địa chỉ ”.
Trước đó trong bài viết này, tôi đã đề cập đến các mối quan tâm khác và một số cách tiếp cận để chuẩn bị cho toàn cầu hóa cơ sở dữ liệu của bạn, như múi giờ và bản dịch (bản địa hóa). Thực tế là không có bài báo nào khác đề cập đến mối quan tâm của các định dạng tiền tệ và ngày tháng đang gây khó khăn. Cơ sở dữ liệu của chúng tôi có được chuẩn bị cho việc sử dụng toàn cầu các ứng dụng của chúng tôi không?
Đề cập Danh dự
Rõ ràng, có những bài viết khác mô tả các lỗi và lỗi thiết kế cơ sở dữ liệu phổ biến, nhưng chúng tôi muốn cung cấp cho bạn một đánh giá rộng rãi về các tài nguyên khác nhau. Bạn có thể tìm thêm thông tin trong các bài báo như:
10 sai lầm khi thiết kế cơ sở dữ liệu phổ biến | Blog Lớp MIS | Ngày 29 tháng 1 năm 2012
10 sai lầm thường gặp trong thiết kế cơ sở dữ liệu | IDG.se | Ngày 24 tháng 6 năm 2010
Tài nguyên Trực tuyến:Bắt đầu từ đâu? Đi đâu?
Như đã đề cập trước đây, danh sách này chắc chắn không phải để kiểm tra toàn bộ mọi bài báo trực tuyến mô tả các lỗi và lỗi thiết kế cơ sở dữ liệu. Thay vào đó, chúng tôi đã xác định một số nguồn đặc biệt hữu ích hoặc có trọng tâm cụ thể mà bạn có thể thấy hữu ích.
Vui lòng giới thiệu các bài viết bổ sung.
