Các mẫu thiết kế cơ sở dữ liệu quan hệ? [đóng cửa]

Các mẫu thiết kế thường liên quan đến thiết kế hướng đối tượng.
Có các mẫu thiết kế để tạo và lập trình cơ sở dữ liệu quan hệ ?
Nhiều vấn đề chắc chắn phải có giải pháp tái sử dụng.

Các ví dụ sẽ bao gồm các mẫu cho thiết kế bảng, quy trình được lưu trữ, kích hoạt, v.v ...

Có một kho lưu trữ trực tuyến các mẫu như vậy, tương tự như martinfowler.com không?

Ví dụ về các vấn đề mà các mẫu có thể giải quyết:

• Lưu trữ dữ liệu phân cấp (ví dụ: bảng đơn có loại so với nhiều bảng có khóa 1: 1 và sự khác biệt ...)
• Lưu trữ dữ liệu với cấu trúc biến (ví dụ: cột chung so với xml so với cột được phân tách ...)
• Không chuẩn hóa dữ liệu (cách thực hiện với tác động tối thiểu, v.v ...)

Có một cuốn sách trong Sê-ri Chữ ký của Martin Fowler có tên là Tái cấu trúc cơ sở dữ liệu . Điều đó cung cấp một danh sách các kỹ thuật để tái cấu trúc cơ sở dữ liệu. Tôi không thể nói rằng tôi đã nghe một danh sách các mẫu cơ sở dữ liệu rất nhiều.

Tôi cũng rất muốn giới thiệu Mô hình mô hình dữ liệu của David C. Hay và Bản đồ siêu dữ liệu tiếp theo được xây dựng trên bản đầu tiên và có nhiều tham vọng và hấp dẫn hơn nhiều. Lời nói đầu một mình là khai sáng.

Ngoài ra, một nơi tuyệt vời để tìm kiếm một số mô hình cơ sở dữ liệu đóng hộp là Tập sách Tài nguyên mô hình dữ liệu tập 1 của Len Silverston Tập 1 chứa các mô hình dữ liệu áp dụng chung (nhân viên, tài khoản, vận chuyển, mua hàng, v.v.), Tập 2 chứa các mô hình dữ liệu cụ thể của ngành (kế toán, chăm sóc sức khỏe, v.v.), Tập 3 cung cấp các mẫu mô hình dữ liệu.

Cuối cùng, trong khi cuốn sách này có vẻ bề ngoài về UML và Mô hình hóa đối tượng, Mô hình hóa màu của Peter Coad với UML cung cấp một quy trình mô hình hóa thực thể theo kiểu "nguyên mẫu" bắt đầu từ tiền đề rằng có 4 nguyên mẫu lõi của bất kỳ mô hình đối tượng / dữ liệu nào

Các mẫu thiết kế không phải là giải pháp tái sử dụng tầm thường.

Các mẫu thiết kế có thể tái sử dụng, theo định nghĩa. Chúng là những mẫu bạn phát hiện trong các giải pháp tốt khác.

Một mô hình không thể tái sử dụng một cách tầm thường. Bạn có thể thực hiện thiết kế xuống của bạn theo mẫu tuy nhiên.

Patters thiết kế quan hệ bao gồm những thứ như:

1. Mối quan hệ một-nhiều (chi tiết tổng thể, cha mẹ-con) sử dụng khóa ngoại.

2. Mối quan hệ nhiều-nhiều với một bảng cầu.

3. Các mối quan hệ một-một tùy chọn được quản lý bằng NULL trong cột FK.

4. Star-Schema: Kích thước và sự thật, thiết kế OLAP.

5. Thiết kế OLTP hoàn toàn bình thường hóa.

6. Nhiều cột tìm kiếm được lập chỉ mục trong một thứ nguyên.

7. "Bảng tra cứu" có chứa PK, mô tả và giá trị mã được sử dụng bởi một hoặc nhiều ứng dụng. Tại sao có mã? Tôi không biết, nhưng khi chúng phải được sử dụng, đây là một cách để quản lý mã.

8. Bàn Uni. [Một số người gọi đây là một mô hình chống; đó là một mô hình, đôi khi nó xấu, đôi khi nó tốt.] Đây là một bảng có rất nhiều thứ được tham gia trước đó vi phạm hình thức bình thường thứ hai và thứ ba.

9. Bảng mảng. Đây là bảng vi phạm hình thức bình thường đầu tiên bằng cách có một mảng hoặc chuỗi các giá trị trong các cột.

10. Cơ sở dữ liệu hỗn hợp. Đây là một cơ sở dữ liệu được chuẩn hóa để xử lý giao dịch nhưng có rất nhiều chỉ mục bổ sung để báo cáo và phân tích. Đó là một mô hình chống - không làm điều này. Mọi người vẫn làm điều đó, vì vậy nó vẫn là một mô hình.

Hầu hết những người thiết kế cơ sở dữ liệu có thể dễ dàng đọc được một nửa tá "Đó là một trong số đó"; đây là những mẫu thiết kế mà họ sử dụng một cách thường xuyên.

Và điều này không bao gồm các mô hình quản lý và vận hành sử dụng và quản lý.

AskTom có lẽ là tài nguyên hữu ích nhất về các thực tiễn tốt nhất trên Oracle DB. (Tôi thường chỉ gõ "asktom" là từ đầu tiên của truy vấn google về một chủ đề cụ thể)

Tôi không nghĩ rằng nó thực sự thích hợp để nói về các mẫu thiết kế với cơ sở dữ liệu quan hệ. Cơ sở dữ liệu quan hệ đã là ứng dụng của "mẫu thiết kế" cho một vấn đề (vấn đề là "cách biểu diễn, lưu trữ và làm việc với dữ liệu trong khi duy trì tính toàn vẹn của nó" và thiết kế là mô hình quan hệ). Các phê duyệt khác (thường được coi là lỗi thời) là các mô hình Điều hướng và Phân cấp (và tôi không có nhiều người khác tồn tại).

Như đã nói, bạn có thể coi "Kho dữ liệu" là một "mẫu" hoặc cách tiếp cận hơi riêng biệt trong thiết kế cơ sở dữ liệu. Cụ thể, bạn có thể thích đọc về lược đồ Sao .

Sau nhiều năm phát triển cơ sở dữ liệu, tôi có thể nói rằng không có vấn đề gì và một số câu hỏi mà bạn nên trả lời trước khi bắt đầu:

câu hỏi:

• Bạn có muốn sử dụng trong tương lai một DBMS khác không? Nếu có thì không sử dụng các công cụ SQL đặc biệt của DBMS hiện tại. Loại bỏ logic trong ứng dụng của bạn.

Không sử dụng:

• khoảng trắng trong tên bảng và tên cột
• Các ký tự không phải chữ Asii trong tên bảng và cột
• ràng buộc với một chữ thường hoặc chữ hoa Và không bao giờ sử dụng 2 bảng hoặc cột chỉ khác nhau với chữ thường và chữ hoa.
• không sử dụng các từ khóa SQL cho các tên bảng hoặc cột như "TỪ", "GIỮA", "XÓA", v.v.

giới thiệu:

• Sử dụng NVARCHAR hoặc tương đương để hỗ trợ unicode sau đó bạn không gặp vấn đề gì với tiền mã hóa.
• Đặt cho mỗi cột một tên duy nhất. Điều này làm cho nó dễ dàng hơn khi tham gia để chọn cột. Sẽ rất khó nếu mỗi bảng có một cột "ID" hoặc "Tên" hoặc "Mô tả". Sử dụng XyzID và AbcID.
• Sử dụng một gói tài nguyên hoặc bằng cho các biểu thức SQL phức tạp. Nó làm cho nó dễ dàng hơn để chuyển sang một DBMS khác.
• Không sử dụng bất kỳ loại dữ liệu nào. Một DBMS khác không thể có kiểu dữ liệu này. Ví dụ: Oracle daes không có SMALLINT chỉ một số.

Tôi hy vọng đây là một điểm khởi đầu tốt.

Câu hỏi của bạn hơi mơ hồ, nhưng tôi cho rằng UPSERTcó thể được coi là một mẫu thiết kế. Đối với các ngôn ngữ không triển khai MERGE, một số giải pháp thay thế để giải quyết vấn đề (nếu tồn tại một hàng phù hợp ;; UPDATEkhác INSERT).

Phụ thuộc những gì bạn có nghĩa là bởi một mô hình. Nếu bạn đang nghĩ Người / Công ty / Giao dịch / Sản phẩm và như vậy, thì có - có rất nhiều lược đồ cơ sở dữ liệu chung đã có sẵn.

Nếu bạn đang nghĩ Factory, Singleton ... thì không - bạn không cần bất kỳ thứ gì trong số này vì chúng quá thấp để lập trình DB.

Nếu bạn đang nghĩ cách đặt tên đối tượng cơ sở dữ liệu, thì nó thuộc danh mục quy ước, không phải thiết kế theo từng se.

BTW, S.Lott, mối quan hệ một-nhiều và nhiều-nhiều không phải là "khuôn mẫu". Chúng là các khối xây dựng cơ bản của mô hình quan hệ.