Cách tốt nhất để mô hình hóa một singleton trong cơ sở dữ liệu quan hệ


12

Khi thiết kế lược đồ cơ sở dữ liệu quan hệ cho các ứng dụng web, tôi thường tìm thấy một trường hợp cuối cùng tôi tạo một bảng chỉ để chứa một hàng và chỉ một hàng. Cảm giác như đó là cách sai để thiết kế nó, nhưng tôi không thể tìm ra thứ gì tốt hơn đáng kể, hoặc đó rõ ràng là "cách đúng đắn để làm điều đó".

Một ví dụ gần đây là một trang web cho phép người dùng kiểm soát nội dung theo cách thủ công trên trang chủ. Chà, chỉ có một trang chủ. Tôi đã tạo một bảng có tất cả các trường cần thiết để xây dựng trang chủ, chẳng hạn như trường văn bản cho một khu vực có chứa văn bản mô tả. Một trường để lưu trữ tên của một tệp hình ảnh lớn. Một số khóa ngoại trỏ đến các bài viết sẽ được giới thiệu trên trang chủ, v.v. Nó hoạt động, nhưng cảm thấy sai khi có một bảng chỉ với một hàng.

Trước đây, tôi đã thử nhiều thiết kế khác, chẳng hạn như cho phép nhiều hàng trong bảng trang chủ và chọn ngẫu nhiên một hàng. Tôi đã thử thêm một trường boolean có tên là "hoạt động" và chọn một trong những trang chủ hoạt động một cách ngẫu nhiên. Tôi đã cố gắng chỉ buộc một hàng hoạt động tại bất kỳ thời điểm nào trong logic ứng dụng. Tôi đã cố gắng thậm chí không tạo một bảng trang chủ và có tất cả các mục khác, chẳng hạn như các bài viết, để có các trường boolean với các tên như đặc trưng_on_homepage.

Trong hầu hết các trường hợp, tôi có thể xây dựng trang chủ với một loạt các hằng số trong tệp cài đặt. Vấn đề chính với tệp cài đặt là nó nằm dưới sự kiểm soát của nhà phát triển. Bởi vì một cái gì đó giống như nội dung của trang chủ là thứ được người dùng chỉnh sửa, nó phải đi vào cơ sở dữ liệu.

Trên nhiều trang web, tôi không gặp phải vấn đề này vì tôi có thể xây dựng những thứ như trang chủ bằng một truy vấn như chọn năm bài viết mới nhất. Nhưng khi tôi có các trang được quản lý thủ công với các yêu cầu nghiêm ngặt, việc mô hình hóa nó trong cơ sở dữ liệu trở nên khó khăn. Nhưng hãy tưởng tượng bạn đã có một bảng ảnh và một bảng bài viết. Yêu cầu là trang chủ sẽ hiển thị chính xác năm ảnh, chính xác ba bài viết và hai khối văn bản tùy ý do người dùng điều khiển thủ công. Làm thế nào để bạn mô hình hóa rằng trong cơ sở dữ liệu đúng cách?

Ngoài ra, tôi có vấn đề mô hình hóa này trong nhiều trường hợp khác ngoài trang chủ. Đó chỉ là ví dụ đơn giản và dễ áp ​​dụng nhất mà tôi có thể đưa ra.


Không rõ vấn đề gì mà bảng một hàng trình bày với bạn, ngoài ra nó theo một cách nào đó thể hiện sự lãng phí của một bảng. Bạn có chắc chắn rằng bạn đang cố gắng giải quyết vấn đề mà bạn thực sự mắc phải không?
David Aldridge

Câu trả lời:


10

Một cách tiếp cận đơn giản là lưu các thuộc tính Trang chủ trong bảng Thuộc tính (hoặc gọi nó là một thứ khác) được tạo thành từ các cột Tên & Giá trị.

HomePageProperty1 - UserValue1

HomePageProperty2 - UserValue2

Nó có thể không phải là một giải pháp lý tưởng, nhưng nó đơn giản và linh hoạt. Nó cũng loại bỏ bảng với kịch bản một hàng.


1
Cách tiếp cận này hoạt động cho nhiều mục đích. Ví dụ: tôi sẽ lưu trữ thông tin phiên bản lược đồ, con trỏ xoay cho những thứ cần được đạp xe hàng ngày, v.v. Thông tin phiên bản lược đồ rất quan trọng khi chẩn đoán lỗi. Đó là một cách hợp lý để đảm bảo một bản vá được áp dụng cho một sửa chữa chỉ có cơ sở dữ liệu.
Berin Loritsch

2
+1 - Đây là cách bố trí bảng chính xác mà Data Architect của chúng tôi đã cho tôi cho một mục đích tương tự.
Ali

3
Vấn đề với cách tiếp cận này là bạn cần biểu diễn các loại biến khác nhau dưới dạng các cột khác nhau và có logic để cho bạn biết nên sử dụng cột nào và cột nào là bắt buộc. Bạn không thể xác định rằng giá trị boolean là boolean hoặc ngày là ngày hoặc thuộc tính cụ thể không thể rỗng hoặc phải nằm trong một phạm vi cụ thể hoặc đáp ứng một điều kiện - tất cả những điều đơn giản không đáng kể với một bảng hàng duy nhất.
David Aldridge

3

Tôi không rõ ràng rằng bạn có một vấn đề mà bạn cần phải giải quyết.

Một bảng đơn hàng không phải là vấn đề đối với chính cơ sở dữ liệu và cho phép bạn áp dụng các loại dữ liệu và các ràng buộc cho dữ liệu.

Tôi không chắc chắn rằng bạn đang cố gắng giải quyết một vấn đề thực sự, thành thật mà nói.


2

Dường như với tôi rằng bạn đang sử dụng một cơ sở dữ liệu cho một cái gì đó thực sự nên được lưu trữ dưới dạng một tệp.

Mô tả của bạn nhắc tôi rất nhiều trang Wiki, nơi người dùng có thể chỉnh sửa nội dung. Trong Wikis, hoặc ít nhất là trong các triển khai tôi đã thấy, các trang được duy trì dưới dạng tệp.

Điều này giúp bạn với các chi tiết web khác như cho phép người dùng lưu trữ trang chủ của bạn, điều này thực tế miễn phí nếu bạn lưu trữ các trang dưới dạng tệp, nhưng bạn phải triển khai logic để vô hiệu hóa bộ đệm nếu bạn đang xây dựng trang trên mỗi yêu cầu dựa trên nội dung được lưu trữ trên cơ sở dữ liệu.

Trong mọi trường hợp, tôi chỉ muốn làm rõ rằng mặc dù hầu hết dữ liệu liên tục của ứng dụng được lưu trữ trong cơ sở dữ liệu, điều đó không có nghĩa là chúng ta phải lưu trữ mọi thứ ở đó. Cơ sở dữ liệu chỉ là một trong những công cụ giao dịch của chúng tôi. Chúng ta phải học cách sử dụng tốt nhiều công cụ khác nhau có thể.


2

Hoàn toàn không có gì sai với một bảng có một hàng.

Nếu đây là một phần trong thiết kế của bạn, bạn nên thực thi nó. Cung cấp cho bảng một cột định danh, cung cấp cho nó một ràng buộc duy nhất, sau đó thêm một ràng buộc cột để chỉ cho phép một giá trị duy nhất. Điều này sẽ đảm bảo rằng không ai có thể thêm hàng thứ hai, điều này có thể là thảm họa nếu các câu lệnh SQL đọc bảng (có thể hiểu được) thiếu mệnh đề where.

Nếu bạn bắt đầu nhận được một số lượng lớn các cột, bạn có thể bị thu hẹp bảng và thay vào đó có một hàng cho mỗi mục cấu hình. Đây không phải là ý tưởng tốt nhất vì bạn mất an toàn và xác nhận loại. Ngoài ra, bạn sẽ mất đi sự tương thích về phía trước với đa nhiệm , điều này có thể quan trọng đối với bạn. Một giải pháp tốt hơn sẽ là xem xét lại thực thể của bạn là gì và có các bảng đơn hàng riêng biệt cho các thực thể khác nhau.

Vâng, tôi không chỉ nói một bảng một hàng là OK, nhưng tôi đề nghị bạn có thể muốn nhiều hơn một trong số họ.


1

Bạn có thể tạo một bảng có tên STATIC_CONTENT và có các cột cho khóa cũng như nội dung, trình theo dõi hoạt động / không hoạt động, v.v. Sau đó, tạo một hàng với khóa "HomePage" và trong trang chủ của bạn, tải nội dung tĩnh cho khóa đó và hiển thị nó. Bằng cách đó, khi bạn có nội dung tĩnh khác (về trang, trang liên hệ, v.v.), bạn có thể thêm hàng vào bảng đó.


1

Không có gì sai khi có một bảng chỉ có một hàng. Nếu bạn chỉ có một thể hiện của một thực thể nhất định, thì đó rất có thể là cách tự nhiên nhất để thể hiện điều này.

Nhưng chọn một hàng ngẫu nhiên là sai và xấu. Nếu logic miền của bạn chỉ mong đợi một hàng duy nhất, thì rõ ràng đó là lỗi trong dữ liệu nếu thực sự có nhiều hơn. Vì vậy, bạn nên tìm ra ai hoặc cái gì đang ghi dữ liệu không hợp lệ vào cơ sở dữ liệu và ngăn họ làm như vậy! Tùy thuộc vào cơ sở dữ liệu, bạn có thể có thể thêm một ràng buộc vào bảng để ngăn điều này xảy ra ở vị trí đầu tiên, ví dụ: chỉ cho phép một giá trị cụ thể làm khóa chính.


0

Chỉ cần thêm vào Walter ..

Cấu trúc bảng thuộc tính nên cho phép nhiều loại dữ liệu.

Fileds:
PropertyName
PropertyTextValue
PropertyDateValue
PropertyNumericValue
PropertyBoolValue

Với điều này, làm thế nào để bạn đảm bảo rằng chỉ có một giá trị tài sản được đặt trên mỗi hàng? Nó đủ dễ để thực thi nó trong ứng dụng, nhưng nếu có ai đó cập nhật cơ sở dữ liệu theo cách thủ công và dính một số dữ liệu trong đó thì sao?
Apreche

0

Dường như với tôi rằng bạn có thể đã trừu tượng hóa một cấp độ hơn. Cuối cùng, "HomePage" là "Trang". Bạn có thể có các loại trang khác nhau với các thuộc tính bạn cần. Nếu bạn có các phần trong trang web của mình, có lẽ bạn cần một "MụcHomePage", có thể hoạt động rất tốt giống như "Trang chủ".

Yêu cầu là trang chủ sẽ hiển thị chính xác năm ảnh, chính xác ba bài viết và hai khối văn bản tùy ý do người dùng điều khiển thủ công. Làm thế nào để bạn mô hình hóa rằng trong cơ sở dữ liệu đúng cách?

Hãy thử nó như thế này. Tôi đang thêm bảng ArticlePage để bạn thấy cách bạn có thể tách các thuộc tính cho phù hợp.

PAGES
Id
Title
Description

HOMEPAGES
PageId (FK)
PhotoListLimit
ArticleListLimit
TextBlockListLimit

ARTICLEPAGE
PageId (FK)
ArticleMainQuote
ArticleMainBody
ArticlePhoto1
ArticlePhoto2

Điều đó sẽ làm việc tốt cho tôi, thậm chí sẽ làm việc tuyệt vời cho một trang web lớn.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.