SQL Server veritabanında Tek Sıralı yapılandırma tablosu kullanma. Kötü bir fikir?

Bir alışveriş sepeti uygulaması geliştirirken, yöneticinin tercihlerine ve gereksinimlerine göre ayarları ve yapılandırmaları kaydetmem gerektiğini buldum. Bu bilgiler şirket bilgileri, Gönderim hesabı kimlikleri, PayPal API anahtarları, bildirim tercihleri ​​vb.

İlişkisel bir veritabanı sisteminde tek bir satırı saklamak için bir tablo oluşturmak son derece uygun görünmemektedir.

Bu bilgileri depolamanın uygun yolu nedir?

Not: DBMS'im SQL Server 2008'dir ve programlama katmanı ASP.NET (C # ile) ile uygulanır.

Geçmişte bu iki yolu yaptım - tek sıralı bir tablo ve bir anahtar / değer çifti tablosu - ve her yaklaşım için olumlu ve olumsuzlar var.

Tek Sıra

• pozitif: değerler doğru tipte saklanır
• pozitif: kodla uğraşmak daha kolaydır (yukarıdakiler nedeniyle)
• pozitif: her ayara ayrı ayrı varsayılan değerler verilebilir
• negatif: yeni bir ayar eklemek için şema değişikliği gerekiyor
• negatif: Çok sayıda ayar varsa tablo çok geniş olabilir

Anahtar / Değer Çifti

• pozitif: yeni ayarlar eklemek şema değişikliği gerektirmez
• pozitif: tablo şeması dar, yeni ayarlar için fazladan satırlar kullanılıyor
• negatif: her ayar aynı varsayılan değere sahiptir (boş / boş?)
• negatif: her şey dize olarak saklanmalıdır (örn. nvarchar)
• negatif: Koddaki ayarlarla uğraşırken, bir ayarın ne tür olduğunu bilmeniz ve yayınlamanız gerekir

Tek sıra seçeneği, çalışmak için en kolay seçenek. Bunun nedeni, her ayarı veritabanında doğru türde saklayabilmeniz ve ayar türlerinin yanı sıra arama anahtarlarını kodda saklamanız gerekmemesidir.

Bu yaklaşımı kullanmakla ilgilendiğim bir şey, "özel" tek sıra ayarları tablosunda birden çok satır olmasıydı. Ben (SQL Server'da) tarafından üstesinden geldi:

• varsayılan değeri 0 olan yeni bir bit sütunu ekleme
• bu sütunun 0 değerine sahip olduğundan emin olmak için bir kontrol kısıtlaması oluşturma
• bit sütununda benzersiz bir kısıtlama oluşturma

Bu, bit sütununun 0 değerine sahip olması gerektiğinden tabloda yalnızca bir satır olabileceği anlamına gelir, ancak benzersiz kısıtlama nedeniyle bu değerle yalnızca bir satır olabilir.

Bilgi türü ve bilgi değeri (en azından) için sütun içeren bir tablo oluşturmalısınız. Bu şekilde, her yeni bilgi eklendiğinde yeni sütunlar oluşturmak zorunda kalmazsınız.

Tek bir satır iyi çalışır; hatta güçlü türleri olacaktır:

show_borders    bit
admin_name      varchar(50)
max_users       int

Bir dezavantajı, alter tableyeni bir ayar eklemek için bir şema değişikliği ( ) gerektirmesidir . Alternatiflerden biri, aşağıdaki gibi bir tabloyla sonuçlandığınız normalleştirmektir:

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

Bu zayıf türlere sahiptir (her şey bir varchartır), ancak yeni bir ayar eklemek sadece bir satır eklemek, sadece veritabanı yazma erişimi ile yapabileceğiniz bir şey.

Şahsen, işe yarayan şeyse tek bir satırda saklayacağım. Bir SQL tablosunda saklamak için gereğinden fazla mı? muhtemelen, ama bunu yaparken gerçek bir zarar yoktur.

Tahmin ettiğiniz gibi ve en basit durumlar dışında, tüm yapılandırma parametrelerini tek bir satıra koymanın birçok dezavantajı vardır. Kötü bir fikir ...

Yapılandırma ve / veya kullanıcı tercihi türü bilgilerini saklamanın kolay bir yolu XML'dir . Birçok DBMS, XML veri türünü destekler. XML sözdizimi, bu yapılandırma geliştikçe yapılandırmayı açıklayan "dili" ve yapıyı harcamanıza olanak tanır. XML'in bir avantajı, hiyerarşik yapı için örtük desteğidir ve örneğin, bunları yapılandırılmış parametrelerin küçük bir listesini numaralandırılmış bir sonekle adlandırmak zorunda kalmadan depolamaya izin verir. XML formatının olası bir dezavantajı, bu verilerin aranması ve genellikle değiştirilmesinin diğer yaklaşımlar kadar basit olmamasıdır (karmaşık bir şey değildir, ancak basit / doğal değildir).

İlişkisel modele daha yakın kalmak istiyorsanız , Entity-Attribute-Value modeli muhtemelen ihtiyacınız olan şeydir, böylece bireysel değerler tipik olarak aşağıdaki gibi bir tabloda saklanır:

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)

AttributeId, her olası Attribute (sizin durumunuzda "yapılandırma parametresi") tanımlanmış bir tablonun yabancı anahtarı olduğundan,

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...)

Son olarak EntityId, bu çeşitli niteliklere "sahip" bazı varlıkları tanımlamanıza izin verir. Sizin durumunuzda bir UserId olabilir, hatta yalnızca yönetilecek bir yapılandırmanız varsa örtük olabilir.

Uygulama geliştikçe olası yapılandırma parametrelerinin listesinin büyümesine izin vermenin yanı sıra, EAV modeli "meta verileri", yani Öznitelik ile ilgili verileri veri tablolarına yerleştirir, böylece yaygın olarak görülen sütun adlarının tüm kodlamasından kaçınır yapılandırma parametreleri tek bir satırda saklandığında.

Normalleştirilmiş yaklaşımda yeni bir yapılandırma parametresi eklerken şemanızı kesinlikle değiştirmeniz gerekmez, ancak yine de muhtemelen yeni değeri işlemek için kodunuzu değiştiriyorsunuzdur.

Dağıtımınıza bir "değiştirme tablosu" eklemek, tek sıralı yaklaşımın basitliği ve tür güvenliği için bir büyüklük gibi görünmüyor.

Bir Anahtar ve Değer çifti, yapılandırma ayarlarını saklayabilen bir .Net App.Config dosyasına benzer.

Yani değeri almak istediğinizde şunları yapabilirsiniz:

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

Bunu yapmanın yaygın bir yolu, bir özellikler dosyasına simüle olan bir "özellikler" tablosuna sahip olmaktır. Burada tüm uygulama sabitlerinizi saklayabilir veya yalnızca sahip olmanız gereken sabit şeyleri saklayamazsınız.

Daha sonra bilgileri gerektiği gibi bu tablodan alabilirsiniz. Benzer şekilde, kaydetmek için başka bir ayarınız olduğunu fark ettiğinizde, ekleyebilirsiniz. İşte bir örnek:

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"   

Bu şekilde sahip olduğunuz verileri ve gelecek yıl sahip olacağınız ve henüz bilmediğiniz verileri saklayabilirsiniz :).

Bu örnekte, kapsamınız ve refD'niz arka uçta istediğiniz herhangi bir şey için kullanılabilir. Yani propertyType "ADMIN" kapsam 0 refId 2 içeriyorsa, bunun ne tercih olduğunu bilirsiniz.

Mülk türü, bir gün yönetici olmayan bilgileri burada da saklamanız gerektiğinde elinize geçer.

Alışveriş sepeti verilerini bu şekilde depolamamanız gerektiğini veya bu konuyla ilgili aramalar yapmayacağınızı unutmayın. Ancak veriler Sisteme özgü ise, bu yöntemi kesinlikle kullanabilirsiniz.

Örneğin: DATABASE_VERSION ürününüzü saklamak istiyorsanız , böyle bir tablo kullanırsınız. Bu şekilde, uygulamayı yükseltmeniz gerektiğinde, istemcinizin yazılımınızın hangi sürümüne sahip olduğunu görmek için özellikler tablosunu kontrol edebilirsiniz.

Mesele şu ki, bunu sepete ait şeyler için kullanmak istemiyorsunuz. İş mantığınızı iyi tanımlanmış ilişkisel tablolarda tutun. Özellikler tablosu yalnızca sistem bilgisi içindir.

Tek bir satırın yapılandırma için en iyi uygulama olduğundan emin değilim. Yapılandırma başına iki sütuna (configName, configValue) sahip bir satır bulundurmak daha iyi olabilir, ancak bu, tüm değerlerinizin dizelere ve arkaya dökülmesini gerektirecektir.

Ne olursa olsun, global yapılandırma için tek bir satır kullanmanın bir zararı yoktur. DB (global değişkenler) içinde saklamak için diğer seçenekler daha kötüdür. İlk yapılandırma satırınızı ekleyerek, ardından birden çok satırı önlemek için tablodaki eklemeleri devre dışı bırakarak kontrol edebilirsiniz.

Her bir ana tür için bir sütun ve verilerin hangi sütunda olduğunu bildiren bir sütun ekleyerek Anahtar / Değer Çifti'ni dönüşüm olmadan yapabilirsiniz.

Yani tablonuz şöyle görünecektir:

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, 

Biraz daha fazla alan kullanıyor ancak en fazla birkaç düzine özellik kullanıyorsunuz. Doğru alanı çekmek / birleştirmek için column_num değerinin dışında bir case deyimi kullanabilirsiniz.

Üzgünüm, geldim, yıllar sonra. Ama her neyse, yaptığım basit ve etkili. Ben sadece üç () sütun içeren bir tablo oluşturun:

Kimlik - int (11)

adı - varchar (64)

değer - metin

Yeni bir yapılandırma sütunu oluşturmadan, güncellemeden veya okumadan önce ne yaptığım "değer" serileştirmektir! Bu şekilde tür eminim (Peki, php :))

Örneğin:

b: 0; için B OOLEAN ( sahte )

b: 1 'dir; için B OOLEAN ( gerçek )

i: 1988; içindir I NT

s: 5: "Kader"; Bir için S 5 karakter uzunluğunda TRING

Umarım bu yardımcı olur :)

Varchar olarak bir anahtar sütun ve JSON olarak bir değer sütun var. 1sayısal, oysa "1"bir dizedir. trueve falseikisi de boolean. Nesneleriniz de olabilir.