Sử dụng bảng cấu hình một hàng trong cơ sở dữ liệu SQL Server. Ý tưởng tồi?

Khi phát triển ứng dụng giỏ hàng, tôi thấy rằng tôi cần lưu các cài đặt và cấu hình dựa trên các yêu cầu và yêu cầu của quản trị viên. Thông tin này có thể là bất cứ thứ gì từ thông tin công ty, ID tài khoản vận chuyển, khóa API PayPal, tùy chọn thông báo, v.v.

Có vẻ rất không phù hợp để tạo một bảng để lưu trữ một hàng trong hệ thống cơ sở dữ liệu quan hệ.

Cách thích hợp để lưu trữ thông tin này là gì?

Lưu ý: DBMS của tôi là SQL Server 2008 và lớp lập trình được triển khai với ASP.NET (trong C #).

Tôi đã thực hiện hai cách này trong quá khứ - một bảng hàng đơn và bảng cặp khóa / giá trị - và có những mặt tích cực và tiêu cực đối với mỗi cách tiếp cận.

Hàng đơn

• dương: các giá trị được lưu trữ đúng loại
• tích cực: dễ dàng hơn để xử lý mã (do những điều trên)
• positive: các giá trị mặc định có thể được cung cấp cho từng cài đặt riêng lẻ
• phủ định: cần phải thay đổi lược đồ để thêm cài đặt mới
• tiêu cực: bảng có thể trở nên rất rộng nếu có nhiều cài đặt

Cặp khóa / giá trị

• tích cực: thêm cài đặt mới không yêu cầu thay đổi lược đồ
• tích cực: lược đồ bảng hẹp, với các hàng bổ sung được sử dụng cho các cài đặt mới
• phủ định: mỗi cài đặt có cùng giá trị mặc định (null / trống?)
• phủ định: mọi thứ phải được lưu trữ dưới dạng chuỗi (ví dụ: nvarchar)
• phủ định: khi xử lý các cài đặt trong mã, bạn phải biết loại cài đặt là gì và truyền nó

Tùy chọn hàng đơn cho đến nay là cách dễ nhất để làm việc. Điều này là do bạn có thể lưu trữ từng cài đặt theo loại chính xác trong cơ sở dữ liệu và không phải lưu trữ các loại cài đặt cũng như các khóa tra cứu của chúng trong mã.

Một điều tôi quan tâm khi sử dụng phương pháp này là có nhiều hàng trong bảng cài đặt hàng đơn "đặc biệt". Tôi đã khắc phục điều này bằng cách (trong SQL Server):

• thêm một cột bit mới với giá trị mặc định là 0
• tạo một ràng buộc kiểm tra để đảm bảo rằng cột này có giá trị 0
• tạo một ràng buộc duy nhất trên cột bit

Điều này có nghĩa là chỉ có một hàng có thể tồn tại trong bảng vì cột bit phải có giá trị 0, nhưng chỉ có thể có một hàng với giá trị đó do ràng buộc duy nhất.

Bạn nên tạo một bảng có một cột cho loại thông tin và giá trị thông tin (ít nhất). Bằng cách này, bạn tránh phải tạo các cột mới mỗi khi thêm thông tin mới.

Một hàng duy nhất sẽ hoạt động tốt; Nó thậm chí sẽ có các loại mạnh:

show_borders    bit
admin_name      varchar(50)
max_users       int

Một nhược điểm là nó yêu cầu thay đổi lược đồ ( alter table) để thêm cài đặt mới. Một cách khác là bình thường hóa, nơi bạn kết thúc với một bảng như:

pref_name       varchar(50) primary key
pref_value      varchar(50) 

Điều này có các loại yếu (tất cả mọi thứ là một varchar), nhưng thêm một cài đặt mới chỉ là thêm một hàng, điều bạn có thể làm chỉ với quyền truy cập ghi cơ sở dữ liệu.

Cá nhân, tôi sẽ lưu trữ nó trong một hàng duy nhất nếu đó là những gì hoạt động. Quá mức cần thiết để lưu trữ nó trong một bảng SQL? có lẽ, nhưng không có hại thực sự khi làm như vậy.

Như bạn đã đoán, và ngoại trừ các tình huống đơn giản nhất, việc đặt tất cả các tham số cấu hình trong một hàng có nhiều nhược điểm. Nó là một ý kiến ​​không hay...

Một cách thuận tiện để lưu trữ cấu hình và / hoặc loại thông tin tùy chọn người dùng có trong XML . Nhiều DBMS hỗ trợ kiểu dữ liệu XML. Cú pháp XML cho phép bạn sử dụng "ngôn ngữ" và cấu trúc mô tả cấu hình khi cấu hình này phát triển. Một lợi thế của XML là sự hỗ trợ ngầm định của nó đối với cấu trúc phân cấp, ví dụ cho phép lưu trữ các danh sách nhỏ các tham số cấu hình mà không phải đặt tên chúng với hậu tố được đánh số. Một nhược điểm có thể có của định dạng XML là việc tìm kiếm và sửa đổi dữ liệu này không đơn giản như các cách tiếp cận khác (không có gì phức tạp, nhưng không đơn giản / tự nhiên)

Nếu bạn muốn tiếp tục gần hơn với mô hình quan hệ , mô hình Entity-Attribution-Value có lẽ là thứ bạn cần, theo đó các giá trị riêng lẻ được lưu trữ trong một bảng thường trông như sau:

EntityId     (foreign key to the "owner" of this attribute)
AttributeId  (foreign key to the "metadata" table where the attribute is defined)
StringValue  (it is often convenient to have different columns of different types
IntValue      allowing to store the various attributes in a format that befits 
              them)

Trong đó AttributionId là khóa ngoại đối với bảng nơi mỗi thuộc tính có thể ("tham số cấu hình" trong trường hợp của bạn) được xác định, với giả sử

AttributeId  (Primary Key)
Name
AttributeType     (some code  S = string, I = Int etc.)
Required          (some boolean indicating that this is required)
Some_other_fields   (for example to define in which order these attributes get displayed etc...)

Cuối cùng, EntityId cho phép bạn xác định một số thực thể "sở hữu" các thuộc tính khác nhau này. Trong trường hợp của bạn, đó có thể là UserId hoặc thậm chí chỉ ẩn nếu bạn chỉ có một cấu hình để quản lý.

Ngoài việc cho phép danh sách các tham số cấu hình có thể phát triển khi ứng dụng phát triển, mô hình EAV đặt "dữ liệu meta", tức là dữ liệu liên quan đến chính Thuộc tính, trong dữ liệu, do đó tránh được tất cả các tên cột được mã hóa cứng thường thấy khi các tham số cấu hình được lưu trữ trong một hàng đơn.

Bạn chắc chắn không phải thay đổi lược đồ của mình khi thêm một tham số cấu hình mới theo cách tiếp cận chuẩn hóa, nhưng có lẽ bạn vẫn thay đổi mã của mình để xử lý giá trị mới.

Thêm một "bảng thay đổi" vào việc triển khai của bạn dường như không phải là một sự đánh đổi lớn vì sự đơn giản và an toàn của kiểu tiếp cận hàng đơn.

Cặp Khóa và Giá trị tương tự như .Net App.Config có thể lưu trữ cài đặt cấu hình.

Vì vậy, khi bạn muốn lấy giá trị bạn có thể làm:

SELECT value FROM configurationTable
WHERE ApplicationGroup = 'myappgroup'
AND keyDescription = 'myKey';

Một cách phổ biến để làm điều này là có một bảng "thuộc tính" mô phỏng theo tệp thuộc tính. Tại đây bạn có thể lưu trữ tất cả các hằng số ứng dụng của mình, hoặc không phải là những thứ liên tục mà bạn chỉ cần có xung quanh.

Sau đó, bạn có thể lấy thông tin từ bảng này khi bạn cần. Tương tự, khi bạn thấy bạn có một số cài đặt khác để lưu, bạn có thể thêm nó vào. Dưới đây là một ví dụ:

property_entry_table

[id, scope, refId, propertyName, propertyValue, propertyType] 
1, 0, 1, "COMPANY_INFO", "Acme Tools", "ADMIN"  
2, 0, 1, "SHIPPING_ID", "12333484", "ADMIN"  
3, 0, 1, "PAYPAL_KEY", "2143123412341", "ADMIN"   
4, 0, 1, "PAYPAL_KEY", "123412341234123", "ADMIN"  
5, 0, 1, "NOTIF_PREF", "ON", "ADMIN"  
6, 0, 2, "NOTIF_PREF", "OFF", "ADMIN"   

Bằng cách này, bạn có thể lưu trữ dữ liệu bạn có và dữ liệu bạn sẽ có trong năm tới và chưa biết về :).

Trong ví dụ này, phạm vi và refId của bạn có thể được sử dụng cho bất cứ điều gì bạn muốn ở mặt sau. Vì vậy, nếu propertyType "ADMIN" có phạm vi 0 refId 2, bạn sẽ biết nó ưu tiên gì.

Loại tài sản có trong tay khi một ngày nào đó, bạn cũng cần lưu trữ thông tin không phải quản trị viên ở đây.

Lưu ý rằng bạn không nên lưu trữ dữ liệu giỏ hàng theo cách này hoặc tra cứu cho vấn đề đó. Tuy nhiên nếu dữ liệu là Hệ thống cụ thể, thì bạn chắc chắn có thể sử dụng phương pháp này.

Ví dụ: Nếu bạn muốn lưu trữ DATABASE_VERSION của mình , bạn sẽ sử dụng một bảng như thế này. Bằng cách đó, khi bạn cần nâng cấp ứng dụng, bạn có thể kiểm tra bảng thuộc tính để xem phiên bản phần mềm của máy khách của bạn.

Vấn đề là bạn không muốn sử dụng cái này cho những thứ liên quan đến giỏ hàng. Giữ cho bạn logic kinh doanh trong các bảng quan hệ được xác định rõ. Bảng thuộc tính chỉ dành cho thông tin hệ thống.

Tôi không chắc chắn một hàng duy nhất là triển khai tốt nhất cho cấu hình. Bạn có thể tốt hơn khi có một hàng cho mỗi mục cấu hình với hai cột (configName, configValue), mặc dù điều này sẽ yêu cầu chuyển tất cả các giá trị của bạn thành chuỗi và ngược lại.

Bất kể, không có hại trong việc sử dụng một hàng cho cấu hình toàn cầu. Các tùy chọn khác để lưu trữ nó trong DB (biến toàn cục) là tồi tệ hơn. Bạn có thể kiểm soát nó bằng cách chèn hàng cấu hình đầu tiên của bạn, sau đó vô hiệu hóa các phần chèn trên bảng để ngăn nhiều hàng.

Bạn có thể thực hiện Cặp khóa / giá trị mà không cần chuyển đổi bằng cách thêm một cột cho từng loại chính và một cột cho bạn biết dữ liệu nằm trong cột nào.

Vì vậy, bảng của bạn sẽ trông giống như:

id, column_num, property_name, intValue, floatValue, charValue, dateValue
1, 1, weeks, 51, , ,
2, 2, pi, , 3.14159, , 
3, 4, FiscYearEnd, , , , 1/31/2015
4, 3, CompanyName, , , ACME, 

Nó sử dụng nhiều phòng hơn một chút nhưng nhiều nhất bạn đang sử dụng vài chục thuộc tính. Bạn có thể sử dụng một câu lệnh tình huống tắt giá trị cột_num để kéo / nối đúng trường.

Xin lỗi tôi đến như thế, yeaars sau. Nhưng dù sao, những gì tôi làm là đơn giản và hiệu quả. Tôi chỉ cần tạo một bảng có ba cột ():

ID - int (11)

tên - varchar (64)

giá trị - văn bản

Những gì tôi làm trước khi tạo một cột cấu hình mới, cập nhật nó hoặc đọc là để tuần tự hóa "giá trị"! Bằng cách này, tôi chắc chắn về loại (Vâng, php là :))

Ví dụ:

b: 0; dành cho B OOLESE ( sai )

b: 1; dành cho B OOLESE ( đúng )

i: 1988; là cho tôi NT

s: 5: "Kader"; dành cho S TRING có độ dài 5 ký tự

Tôi hi vọng cái này giúp được :)

Có một cột khóa là varchar và cột giá trị là JSON. 1là số trong khi đó "1"là một chuỗi. truevà falseđều là boolean. Bạn có thể có các đối tượng là tốt.