13 bài viết trên blog về các thủ thuật và phương pháp thiết kế cơ sở dữ liệu tốt nhất

Có rất nhiều điều cần lưu ý khi bạn thiết kế cơ sở dữ liệu và rất ít người trong chúng ta có thể nhớ mọi mẹo và thủ thuật có giá trị mà chúng ta đã học được. Vì vậy, hãy cùng xem qua một số tài nguyên trực tuyến có các mẹo thiết kế cơ sở dữ liệu và các phương pháp hay nhất. Khi chúng ta tiếp tục, tôi sẽ chia sẻ ý kiến ​​của riêng mình về các ý tưởng được trình bày, dựa trên kinh nghiệm của tôi trong thiết kế cơ sở dữ liệu.

Rõ ràng, bài viết này không phải là một danh sách đầy đủ, nhưng tôi đã cố gắng xem xét và nhận xét trên nhiều nguồn. Hy vọng rằng bạn sẽ tìm thấy thông tin phù hợp nhất với nhu cầu và mục tiêu của mình.

Cũng cần lưu ý thêm, tôi rất ngạc nhiên khi thấy rằng nhiều bài báo liên quan đến thực hành thiết kế cơ sở dữ liệu có rất ít ví dụ; các tài nguyên trực tuyến mà tôi đã xem xét cho bài viết về lỗi và sai lầm có tỷ lệ phần trăm trong số đó cao hơn. Sự thiếu sót này là một nhược điểm, bởi vì các ví dụ là cực kỳ quan trọng để hiểu được vấn đề.

Mẹo về cơ sở dữ liệu dành cho nhà thiết kế có kinh nghiệm

Trước tiên, hãy bắt đầu với các nguồn có các mẹo thiết kế cơ sở dữ liệu nâng cao và các phương pháp hay nhất. Những thứ này dành cho những nhà thiết kế đã làm việc trong lĩnh vực mô hình dữ liệu và đã làm việc được một thời gian. Một số bài viết hướng đến trình độ trung cấp hơn, nhưng nếu chúng thảo luận về các khái niệm nâng cao, tôi đã đưa chúng vào danh sách này.

Nguyên tắc Cơ sở dữ liệu (RDBMS / SQL)

bởi Steve Djajasaputra | SOA, Java, Phát triển phần mềm - BlogSpot | Ngày 16 tháng 1 năm 2013

Bài viết này của ông Djajasaputra khá ấn tượng:ông liệt kê rất nhiều mẹo cho lược đồ, chỉ mục và chế độ xem; ông cũng cung cấp một quy ước đặt tên khá chi tiết. Và lời khuyên của anh ấy tiếp tục (và tiếp tục). Bề rộng là rất ấn tượng, nhưng hầu như không có ví dụ nào. Một số điểm của anh ấy có thể được coi là gây tranh cãi, nhưng nhìn chung thì đây là một bài thuyết trình rất chắc chắn.

Đặc biệt, tôi rất ấn tượng khi anh ấy đưa ra một quy tắc chính xác về việc sử dụng khóa chính tự nhiên so với nhân tạo (tức là thay thế hoặc được tạo). Anh ấy giữ điều này hay và đơn giản, nói rõ rằng chúng ta nên thích một khóa tự nhiên hơn vì nó có ý nghĩa. Ông cũng đưa ra các hướng dẫn để sử dụng tốt nhất khóa nhân tạo – cụ thể là khi khóa tự nhiên không phải là duy nhất hoặc khi bạn cần thay đổi giá trị của khóa tự nhiên. Nói theo cách của mình:

Vì danh sách các mẹo của anh ấy quá dài, tôi không thể tưởng tượng là sẽ nhớ hết chúng. Nhưng mỗi phần có thể được tham chiếu khi bạn đang làm việc trên thiết kế cơ sở dữ liệu, hiệu suất, thủ tục được lưu trữ và lập phiên bản. Ngoài ra còn có một phần về các điểm cụ thể của Oracle sẽ hữu ích nếu bạn đang làm việc với hoặc dự định hỗ trợ Oracle.

Nói chung, đây là một nguồn tài nguyên rất đáng giá và toàn diện.

9 Mẹo để Thiết kế Cơ sở dữ liệu Tốt hơn

của Jeffrey Edison | Vertabelo Blog | Ngày 22 tháng 9 năm 2015

Tôi sẽ thưởng thức một chút tự quảng cáo ở đây.

Bài viết gồm 9 mẹo để thiết kế cơ sở dữ liệu tốt hơn dựa trên kinh nghiệm của tôi với tư cách là một nhà thiết kế và kiến ​​trúc sư. Tôi cũng tìm thấy thêm thông tin chi tiết từ việc nghiên cứu các phương pháp hay nhất của những người khác để thiết kế cơ sở dữ liệu.

Danh sách của tôi đại diện cho một số vấn đề chính có thể xảy ra khi làm việc với mô hình dữ liệu. Tôi sắp xếp các mẹo theo thứ tự chúng xuất hiện trong vòng đời của dự án (thay vì theo tầm quan trọng hoặc tần suất chúng phát sinh) vì điều đó sẽ hữu ích nhất, ít nhất là theo quan điểm của tôi. Người đọc có thể theo dõi danh sách kiểm tra các phương pháp hay nhất này trong suốt vòng đời của một dự án.

Từ bài báo:

Bằng cách chú ý đến những mẹo này, tôi nhận thấy rằng cơ sở dữ liệu trở nên được thiết kế tốt hơn và mạnh mẽ hơn. Mặc dù không có hoạt động nào trong số này sẽ tốn rất nhiều thời gian, nhưng mỗi hoạt động có thể có tác động to lớn đến chất lượng mô hình dữ liệu của bạn.

Tôi hy vọng rằng danh sách các mẹo của tôi hữu ích cho các nhà thiết kế trung cấp và cao cấp.

20 Thực tiễn Tốt nhất về Thiết kế Cơ sở dữ liệu

bởi Cagdas Basaraner | Số dư mã - BlogSpot | Ngày 24 tháng 7 năm 2011

Ông Basaraner giới thiệu cho chúng ta một danh sách thú vị gồm 20 phương pháp hay nhất về thiết kế cơ sở dữ liệu. Tôi sẽ thích nó hơn nếu anh ta nhóm một số trong số này; ví dụ:tất cả bốn mục đầu tiên có thể được đề cập trong "Sử dụng các quy ước đặt tên tốt".

Ngoài ra, ông nói rằng sử dụng ID tổng hợp, được tạo (số nguyên) làm khóa chính của tất cả các bảng là một phương pháp hay nhất. Trên thực tế, đây vẫn là một chủ đề được tranh luận, có lý lẽ ủng hộ và phản đối. Một số phương pháp hay nhất của anh ấy khá chung chung, như “Đối với… hệ thống cơ sở dữ liệu của nhà phê bình nhiệm vụ [sic], sử dụng dịch vụ khôi phục thảm họa và bảo mật…” Tôi không đồng ý với điểm này, nhưng nó rất cao cấp.

Về mặt tích cực, bài viết này là một trong số ít đề cập đến việc sử dụng khuôn khổ ánh xạ quan hệ đối tượng (ORM). Một số người bình luận không đồng ý với cách viết mẹo, nhưng ít nhất sử dụng khung ORM đã được đề cập:

Tuy nhiên, danh sách này có thể đã được cải thiện. Nó phải xác định rõ ràng các điểm chỉ cụ thể cho một số hệ quản trị cơ sở dữ liệu (ví dụ, SQL Server). Số liệu thống kê chính xác về hiệu suất, kinh nghiệm học hoặc tầm quan trọng của việc dành thời gian cho thiết kế thay vì bảo trì và thiết kế lại sẽ tốt. Cũng cần có thêm các ví dụ, nhưng đó là một vấn đề đối với hầu hết các bài báo này.

Nếu bạn đang làm việc với SQL Server, đang cân nhắc sử dụng khung ORM hoặc cần một danh sách các mẹo có dấu đầu dòng thay vì một bài viết dài và chi tiết, thì phần này là dành cho bạn.

(Lưu ý:bài viết này cũng xuất hiện trên một số trang web khác, bao gồm CodeBuild, Java Code Geeks và DZone.)

Cơ bản về Thiết kế Cơ sở dữ liệu. 10 điều bạn nhất thiết phải làm

của Michelle A. Poolet | SQL Server Pro | Ngày 1 tháng 3 năm 2011

Một số mẹo của cô Poolet là khá chuẩn và có thể được tìm thấy trong nhiều tài nguyên khác, nhưng cũng có một số điểm khá bất thường. Trong số các quan điểm chung của mình, cô ấy khuyến khích việc sử dụng các loại phụ và siêu loại (tôi hoàn toàn đồng ý) vì điều này phản ánh thiết kế hướng đối tượng và các nhà phát triển có thể dễ dàng hiểu được. Từ bài viết của cô ấy:

Đừng ngại bao gồm các thực thể supertype và subtype trong thiết kế của bạn trong CDM trở đi. Các kiểu con đại diện cho các phân loại hoặc danh mục của siêu kiểu… Các thực thể được biểu thị dưới dạng các kiểu con khi cần nhiều hơn một từ hoặc cụm từ để phân loại thực thể.

Nếu một danh mục có thời gian tồn tại của riêng nó, với các thuộc tính riêng biệt mô tả giao diện và hoạt động của danh mục cũng như các mối quan hệ riêng biệt với các thực thể khác, thì đã đến lúc gọi cấu trúc supertype / subtype . Nếu không làm như vậy sẽ hạn chế sự hiểu biết đầy đủ về dữ liệu và các quy tắc kinh doanh thúc đẩy việc thu thập dữ liệu.

Một số nhận xét của cô ấy tham chiếu cụ thể đến MS SQL Server ngay cả khi các nhận xét đó thực sự là các vấn đề chung chung. Một điểm chính mà cô Poolet đưa ra là rất cụ thể về SQL Server:“Mã lưu trữ tiếp xúc với dữ liệu của cơ sở dữ liệu như một quy trình được lưu trữ”.

Điều này là tốt nếu bạn chỉ định hỗ trợ một hệ thống quản lý cơ sở dữ liệu duy nhất, chẳng hạn như SQL Server. Nhưng đối với các triển khai di động, đây sẽ không phải là lời khuyên tốt. Nói chung, tôi thiết kế để có thể chuyển sang ít nhất hai hệ thống quản lý với sự hỗ trợ ngôn ngữ thủ tục được lưu trữ khác nhau. Do đó, tôi sẽ tránh thực hành này.

Bài viết này hữu ích nhất cho những người đang phát triển SQL Server và tập trung vào thị trường Mỹ (thay vì một hệ thống quốc tế). Tuy nhiên, là một người Mỹ sống ở nước ngoài, tôi thấy rằng một số ví dụ của cô ấy hơi quá “lấy Hoa Kỳ làm trung tâm”. Ví dụ:một người không phải là người Mỹ có thể không hiểu Zip + 4 là gì miền và do đó sẽ không hiểu tại sao miền này phải có đặc tính KHÔNG ĐỦ.

Để minh họa điều này, tôi đã tạo một mô hình dữ liệu cho cả các địa chỉ người Mỹ không phải là người Mỹ. Chúng tôi sẽ giả định rằng mô hình dữ liệu của chúng tôi có thể yêu cầu các thực thể được liên kết với nhiều địa chỉ:ví dụ:một để thanh toán, một để giao hàng. Địa chỉ đầu tiên sẽ được liên kết với một phương thức thanh toán; trong trường hợp này, địa chỉ sẽ được sử dụng để xác minh quyền cho phép thanh toán đó của bạn. Địa chỉ giao hàng, rõ ràng, là nơi đơn hàng sẽ được giao.

Hãy tạo địa chỉ Mỹ như một phần của mô hình cơ sở dữ liệu đơn đặt hàng của khách hàng. (Lưu ý:đây không phải là một mô hình hoàn chỉnh mà là một ví dụ về lưu trữ đơn đặt hàng sản phẩm.)

Wise Coders Solutions khuyên bạn nên xác định các trường riêng biệt cho số nhà và tên đường và đặt các trường này là KHÔNG ĐỦ; điều này sẽ không cho phép bất kỳ địa chỉ nào không có số nhà và tên đường. Nhưng những người sử dụng hộp thư bưu điện thì sao? Địa chỉ của họ thường được viết là “Hộp thư bưu điện 123”. Chúng ta có nên bắt họ đặt số PO Box làm số nhà và “PO Box” làm tên đường không? Tôi không nghĩ vậy.

Thay vào đó, chúng tôi sẽ sử dụng biểu mẫu có “Dòng địa chỉ 1” và “Dòng địa chỉ 2”. Một số người đã tranh luận chống lại việc sử dụng số trong tên trường, nhưng đối với tôi đây là một giải pháp khá rõ ràng. Ngoài ra, tôi đã xác định độ dài trường tối đa (35 và 70 ký tự) thường thấy trong thanh toán quốc tế.

Lưu ý rằng các thiết kế của Hoa Kỳ và không phải của Hoa Kỳ đều có trường cho các vùng trong một quốc gia, nhưng thiết kế của Hoa Kỳ yêu cầu phải bao gồm cả 2 ký tự viết tắt của tiểu bang. Ngoài ra, hãy lưu ý rằng thiết kế của Hoa Kỳ không cho phép địa chỉ ở các quốc gia khác.

Nếu bạn lo lắng về việc sử dụng toàn cầu cơ sở dữ liệu của mình, bạn cần phải suy nghĩ toàn cầu trong giai đoạn thiết kế. Cơ sở dữ liệu của chúng tôi có được chuẩn bị cho việc sử dụng các ứng dụng của chúng tôi ở nhiều quốc gia không?

Bài học rút ra từ thiết kế kho dữ liệu kém

của Michelle A. Poolet | SQL Server Pro | Ngày 15 tháng 6 năm 2009

Bài viết này xem xét Kho dữ liệu (DWH) và một số vấn đề về thiết kế và triển khai của nó. Có một chút tập trung vào SQL Server, nhưng đó là một tổng quan khá chính thống về thiết kế cho kho dữ liệu và thông minh kinh doanh. Mua vào và tạo giao diện thân thiện với người dùng có thể không phải là mẹo hữu ích nhất, nhưng tôi không đồng ý với chúng - tôi chỉ không nghĩ chúng là một phần của thiết kế DWH.

Bà Poolet nói rằng quá trình trích xuất-chuyển đổi-tải (ETL) nên thực hiện kiểm tra chất lượng dữ liệu và dữ liệu có khả năng "sạch" cho đến khi có một tiêu chuẩn chấp nhận được về chất lượng dữ liệu. Theo tôi, điều này có nguy cơ tạo ra một kho dữ liệu không phản ánh đúng thông tin được trích xuất từ ​​hệ thống nguồn. Làm sạch dữ liệu nên được thực hiện trong hệ thống nguồn. ETL chỉ nên chuyển đổi dữ liệu để nó có thể được tải vào kho dữ liệu.

Một lưu ý tích cực, khuyến nghị tái chế hoặc tạo các quy trình ETL có thể tái sử dụng là rất phù hợp. Ngoài ra, tôi đồng ý với cô Poolet về khả năng mở rộng. Nhận xét của cô ấy về quản lý rủi ro và tuân thủ, đặc biệt là Đạo luật Sarbanes-Oxley, có vẻ khá cụ thể; Tôi giả định rằng những điều này đến từ lĩnh vực kinh doanh của cô ấy.

Cuối cùng, cô ấy có một danh sách kiểm tra tuyệt vời về các điểm liên quan đến kích thước, bảng dữ kiện và các lựa chọn lược đồ trong quá trình thiết kế OLAP (xử lý phân tích trực tuyến). Những điều này dường như rất phù hợp trong quá trình thiết kế cơ sở dữ liệu. Tôi muốn danh sách này dài hơn, với nhiều chi tiết hoặc ví dụ hơn, nhưng tôi rất vui vì những mẹo thiết thực này đã được đưa vào.

11 Quy tắc thiết kế cơ sở dữ liệu quan trọng mà tôi tuân theo

bởi Shivprasad Koirala | Mã dự án | Ngày 25 tháng 2 năm 2014

Tôi thực sự thích những lời khuyên hợp lý và rõ ràng ở đầu bài viết này. Các khái niệm như "xem xét bản chất của ứng dụng" và "chia dữ liệu của bạn thành các phần hợp lý" được đưa ra. Đây là những trợ giúp quan trọng khi tạo mô hình dữ liệu của bạn. Như ông Koirala nói:

Tuy nhiên, có một vài điểm khiến tôi chưa thuyết phục. Ví dụ:lấy các cặp Tên-Giá trị tập trung vào một bảng duy nhất. Thiết kế One True Lookup Table (OTLT) này đang được tranh luận, nhưng nó thường được coi là một thực hành xấu hoặc ít nhất là chống lại khuôn mẫu trong thiết kế. 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 tôi có thể sử dụng phương pháp tương tự phát triển phần mềm 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ể tương đương với thực tiễn này.

Để 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. Tôi đồng ý với nhóm chống OTLT; các bảng này giới thiệu nhiều vấn đề.

Ngoài ra, một số điểm có vẻ hơi bí truyền, chẳng hạn như "để ý dữ liệu được phân tách bằng dấu phân cách". Mặc dù đây là một điểm hợp lệ, nhưng nó không phải là một điểm mà tôi thường nghĩ đến khi tạo một mô hình dữ liệu mới.

Ông Koirala có một vài hạng mục thiết kế OLAP thường không được đề cập trong các danh sách thực hành tốt nhất khác. Việc anh ấy đưa vào thiết kế thứ nguyên và dữ kiện có thể hữu ích, nhưng nó cũng có thể nguy hiểm cho các nhà thiết kế mới.

Bài viết này rất thú vị nếu bạn đang chuyển từ đầu sang mô hình dữ liệu nâng cao hơn. Nó sẽ giúp bạn xem xét bản chất phân tích so với giao dịch của các mô hình tương lai của bạn.

Dữ liệu lớn:Năm Mẹo Hiệu suất Thiết kế Cơ sở dữ liệu Đơn giản

bởi Dave Beulke | davebeulke.com | Ngày 19 tháng 3 năm 2013

Bài viết của ông Beulke đề cập đến các mẹo thiết kế tập trung vào hiệu suất. Anh ấy chỉ cách kiểm tra sự bình thường thích hợp:không quá nhiều cũng không quá ít. (Chuẩn hóa quá mức sẽ có tác động tiêu cực đến hiệu suất cơ sở dữ liệu.)

Ngoài ra, sử dụng khóa nghiệp vụ tự nhiên thay vì khóa chính được tạo là lời khuyên hợp lý khi bạn muốn tránh dịch từ khóa nghiệp vụ sang ID hàng được tạo cho mỗi lần truy cập cơ sở dữ liệu.

Sử dụng các tiêu chuẩn đặt tên và kiểu cột thích hợp cũng là một lời khuyên tốt. Điểm đáng chú ý về việc lạm dụng cột nullable là rất hợp lý:việc tạo tất cả các cột là 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ể. Theo lời của chính tác giả:

Tất cả các mẹo của ông Beulke đều rất chắc chắn, ngay cả khi có phần không nguyên bản. Tôi thích các mục Dữ liệu lớn hơn - sau cùng, đó là tiêu đề của bài báo. Cuối cùng, tôi cảm thấy rằng bài viết thiếu cả chiều sâu và chiều rộng, và không có ví dụ để làm rõ các điểm. Tuy nhiên, anh ấy đưa ra lời khuyên có giá trị liên quan đến chuẩn hóa và khóa tự nhiên.

10 Thực tiễn Tốt nhất về Thiết kế Cơ sở dữ liệu

bởi Ann All | Ứng dụng doanh nghiệp ngày nay | Ngày 15 tháng 7 năm 2014

Mười Thực tiễn Tốt nhất về Thiết kế Cơ sở dữ liệu thực sự được trình bày dưới dạng một loạt các trang trình bày. Cô Tất cả bao gồm thông tin từ các nhà phát triển dày dạn, chẳng hạn như Michael Blaha. Anh ấy khuyến khích việc sử dụng lại các mô hình và phương pháp hay nhất của bạn. Những điều này đã được hiểu và chứng minh, và về mặt đó, phù hợp hơn với các mô hình dữ liệu phải được tạo từ đầu. Từ bài viết của Ms. All:

Đây là một trình chiếu ngắn mà các nhà thiết kế mô hình dữ liệu có thể nhanh chóng quét qua và thu thập các mẹo phù hợp với họ. Đối với tôi, mẹo sử dụng lại là một trong những mục yêu thích của tôi.

Các phương pháp hay nhất về cơ sở dữ liệu

bởi Cunningham &Cunningham, Inc.

Các phương pháp hay nhất này bắt đầu tốt nhưng sau đó gặp phải một số vấn đề khó khăn. Tôi không tin rằng lời khuyên đưa ra luôn đúng.

Về mặt tích cực, có những mô tả rất hay về “các phương pháp hay nhất” gây tranh cãi như luôn sử dụng khóa thay thế được tạo tự động và sử dụng hoặc tránh các thủ tục được lưu trữ. Ví dụ:

(Ghi chú của tác giả:Tôi không thể tìm thấy “tác giả trước đây” này khi tìm kiếm hai câu này trên Google.)

Và một liên kết đến bài viết tóm tắt về các đối số chính ở mỗi bên của cuộc tranh luận Chìa khóa tự động so với Chìa khóa miền được cung cấp.

Mặt khác, tôi thấy các mẹo để “phân chia hệ điều hành, dữ liệu và đăng nhập vào các đĩa vật lý khác nhau” và “sử dụng RAID” hơi phức tạp. Đừng hiểu sai ý tôi - đây có thể là lời khuyên đúng đắn trong một số trường hợp, nhưng tôi sẽ không đưa nó vào danh sách 20 người hàng đầu của mình.

Mẹo thiết kế cơ sở dữ liệu

bởi Wise Coders

Có một số mẹo độc đáo và thú vị trong bộ sưu tập này, chẳng hạn như khuyến nghị đóng giao dịch càng sớm càng tốt.

Tuy nhiên, tôi không hoàn toàn đồng ý với tất cả các mẹo thiết kế ở đây. Ví dụ:

Điều này gây tranh cãi, nói ít nhất - các nguồn khác khuyến cáo không nên sử dụng "mã bí mật" như thế này. Thay vào đó, hãy sử dụng một bảng riêng để lưu trữ các mã trạng thái này.

Ngoài ra, các số liệu thống kê liên quan đến các gợi ý về hiệu suất còn đáng nghi ngờ và không có ví dụ nào trong bài viết.

Một lưu ý tích cực, đây là danh sách ngắn các mẹo hay mà các nhà lập mô hình cơ sở dữ liệu trung gian có thể truy cập được.

Tài nguyên dành cho người mới bắt đầu thiết kế cơ sở dữ liệu

Bây giờ chúng ta hãy xem xét một vài bài báo dành cho những người mới bắt đầu thiết kế cơ sở dữ liệu.

Khái niệm cơ bản về thiết kế cơ sở dữ liệu tốt trong phát triển web

bởi Kayla Knight | Onextrapixel.com | Ngày 17 tháng 3 năm 2011

Ở đây chúng tôi nâng cao hơn một chút, với lời khuyên từ chức năng đến các công cụ tạo mô hình.

Cô Knight hướng dẫn chúng tôi qua phần giới thiệu về thiết kế cơ sở dữ liệu. Bài viết của cô ấy rất thú vị vì nó nhấn mạnh đến cơ sở dữ liệu để phát triển web. Mặc dù vậy, những điểm của cô ấy khá phổ quát và có thể áp dụng vào thiết kế cơ sở dữ liệu trong nhiều tình huống.

Bài viết bắt đầu với việc yêu cầu chúng tôi suy nghĩ rộng hơn về chức năng, không chỉ về cơ sở dữ liệu:

Từ đó, cô Knight đưa người đọc vào các công cụ thiết kế cơ sở dữ liệu và các bước liên quan trong quy trình. Bài viết của cô ấy đưa ra các ví dụ và liên kết đến các tài nguyên khác.

Tôi nghĩ rằng bài viết này sẽ là một phần giới thiệu tuyệt vời cho những nhà thiết kế cơ sở dữ liệu mới bắt đầu và nó sẽ hoạt động tốt với Geek Girl’s hàng loạt.

Khám phá các mẹo thiết kế cơ sở dữ liệu

của Doug Lowe | Đối với hình nộm

Danh sách "Những hình nộm" của ông Lowe là một loạt các mẹo thiết kế cơ bản. Bạn có thể tìm thấy nhiều thứ này ở những nơi khác, nhưng sẽ rất hữu ích nếu bạn có chúng ở một nơi. Bạn sẽ không tìm thấy bất kỳ điều gì độc đáo hoặc gây nhiều tranh cãi, ngoại trừ một khuyến nghị sử dụng các quy trình được lưu trữ. Tôi luôn đặt câu hỏi về tuyên bố mạnh mẽ này, vì tôi rất lo lắng về tính khả chuyển của mô hình dữ liệu cho nhiều hệ thống DBM.

Đây là một trong những mẹo thông thường của ông Lowe:

Các khuyến nghị này phù hợp nhất khi làm việc với SQL Server.

Năm mẹo thiết kế cơ sở dữ liệu đơn giản

bởi Lamont Adams | TechRepublic | Ngày 25 tháng 6 năm 2001

Từ khóa cho tài nguyên này là "đơn giản". Bạn có thể tìm thấy thông tin này, với nhiều giải thích và ví dụ hơn, trong các bài viết khác.

Tuy nhiên, lời khuyên của ông Adams là “Hãy lấy chìa khóa của người dùng đi” là một điểm thú vị, hiếm khi được đề cập ở những nơi khác. Anh ấy tiếp tục:

Ý của ông Adams là bạn nên xem xét yêu cầu tiềm năng của người dùng để chỉnh sửa các trường khi quyết định sử dụng trường nào làm khóa. Tôi muốn giải thích nhiều hơn về các lựa chọn thay thế, chẳng hạn như khóa tổng hợp / được tạo, nhưng khái niệm này là tốt.

Tôi đã không đồng ý với điểm cuối cùng. Anh ấy đề xuất một "yếu tố fudge" cho mỗi bảng bạn thiết kế:

Theo suy nghĩ của tôi, đây về cơ bản là "thêm một vài trường văn bản bổ sung vào cuối." Điều này dường như mâu thuẫn với một số lời khuyên khác của ông Adams, đặc biệt là những lời khuyên liên quan đến việc hiểu nhu cầu kinh doanh và sử dụng những cái tên có ý nghĩa. Các trường fudge bổ sung này sẽ chỉ được gọi là “extra1” hoặc “extra2”. Nhu cầu kinh doanh của họ là gì? Và những cái tên ý nghĩa này như thế nào? Mặc dù tôi thích hầu hết các mẹo thiết kế của anh ấy, nhưng “yếu tố giả mạo” này không phải là thứ mà tôi tuân thủ.

Thiết kế Cơ sở dữ liệu:Đề cập Danh dự

Rõ ràng, có những bài viết khác mô tả các mẹo thiết kế cơ sở dữ liệu và các phương pháp hay nhất. Bạn có thể tìm tài liệu bổ sung trong các liên kết sau:

Thiết kế cơ sở dữ liệu quan hệ:Sơ đồ thực tiễn tốt nhất | bởi Digital Ethos | Ngày 24 tháng 12 năm 2012

Các phương pháp hay nhất để thiết kế lược đồ cơ sở dữ liệu (Người mới bắt đầu) | bởi Jim Murphy | Ngày 28 tháng 3 năm 2011

Các phương pháp hay nhất về CNTT:Thiết kế cơ sở dữ liệu | của Đại học Nebraska – Lincoln

Tài nguyên thiết kế cơ sở dữ liệu trực tuyến:Bạn sẽ đi đâu?

Như đã đề cập, danh sách này chắc chắn không phải là một cuộc kiểm tra toàn diện mọi bài báo về thiết kế cơ sở dữ liệu trên Internet. Thay vào đó, chúng tôi đã xác định một số bài báo mà chúng tôi cho là 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.