İlişkisel bir veritabanında tekil bir modellemenin en iyi yolu

Web uygulamaları için ilişkisel veritabanı şeması tasarlarken, genellikle bir satır ve yalnızca bir satır içerecek bir tablo oluşturduğum bir durum bulurum. Bunu tasarlamanın yanlış yolu gibi hissettiriyor, ancak önemli ölçüde daha iyi bir şey bulamıyorum veya açıkçası "bunu yapmanın doğru yolu".

Yeni bir örnek, kullanıcıların ana sayfadaki içeriği manuel olarak kontrol etmesine izin veren bir sitedir. Sadece bir ana sayfa var. Açıklayıcı metin içeren bir alan için metin alanı gibi ana sayfayı oluşturmak için gerekli tüm alanlara sahip bir tablo oluşturdum. Büyük bir görüntü dosyasının adını depolamak için kullanılan alan. Ana sayfada yer alacak makalelere işaret eden bazı yabancı anahtarlar vb. Çalışır, ancak sadece bir satır içeren bir tabloya sahip olmak yanlış hisseder.

Geçmişte, ana sayfa tablosunda birden çok satıra izin vermek ve rastgele birini seçmek gibi birçok tasarım denedim. Ben "aktif" adlı bir boole alan ekleme ve rastgele etkin ana sayfalarından birini seçerek denedim. Ben sadece bir satır uygulama mantığında herhangi bir zamanda aktif olmaya zorladım. Hatta bir anasayfa tablo yapma ve özellikli_on_homepage gibi isimleri ile boolean alanları olması için, makaleler gibi diğer tüm öğeleri sahip denemedim.

Çoğu durumda ana sayfayı bir ayarlar dosyasında bir sürü sabit ile oluşturabilirim. Ayarlar dosyasıyla ilgili temel sorun, geliştirici kontrolünde olmasıdır. Ana sayfanın içeriği gibi bir şey kullanıcı tarafından düzenlenecek bir şey olduğundan, veritabanına girmesi gerekir.

Birçok sitede, bu soruna sahip değilim çünkü en yeni beş makaleyi seçmek gibi bir sorgu ile ana sayfa gibi şeyler oluşturabilirim. Ancak, katı gereksinimlerle el ile küratörlenmiş sayfalar olduğunda, veritabanında modellemek zorlaşır. Ama bir fotoğraf tablonuz ve bir makale tablonuz olduğunu düşünün. Gereksinim, ana sayfada tam olarak beş fotoğraf, tam olarak üç makale ve kullanıcı tarafından manuel olarak kontrol edilen iki rastgele metin bloğu görüntülenmesi. Bunu veritabanında doğru şekilde nasıl modellersiniz?

Ayrıca, sadece ana sayfaların yanı sıra birçok durumda bu modelleme problemim var. Bu sadece benim karşılaşabileceğim en kolay ve en genel olarak uygulanabilir örnek.

Basit bir yaklaşım, Ana Sayfa özelliklerini Ad ve Değer sütunlarından oluşan bir Özellikler tablosuna kaydetmek (veya başka bir şey olarak adlandırmak) olacaktır.

HomePageProperty1 - KullanıcıDeğer1

HomePageProperty2 - KullanıcıDeğer2

İdeal bir çözüm olmayabilir, ancak basit ve esnektir. Ayrıca tabloyu tek satırlık senaryo ile ortadan kaldırır.

Çözmeniz gereken bir sorununuz olduğu açık değil.

Tek satırlı bir tablo hiçbir şekilde veritabanının kendisi için bir sorun oluşturmaz ve verilere veri türleri ve kısıtlamalar uygulamanıza izin verir.

Dürüst olmak gerekirse gerçek bir sorunu çözmeye çalıştığınızdan emin değilim.

Bana öyle geliyor ki, aslında bir dosya olarak depolanması gereken bir şey için bir veritabanı kullanıyorsunuz.

Açıklamanız bana kullanıcıların içeriği düzenleyebileceği birçok Wiki sayfasını hatırlatıyor. Vikisözlerde veya en azından gördüğüm uygulamalarda, sayfalar dosya olarak kalıcıdır.

Bu, kullanıcılarınızın ana sayfanızı önbelleğe almasına izin vermek gibi diğer web ayrıntılarında size yardımcı olur, bu da sayfaları dosya olarak saklarsanız pratik olarak ücretsizdir, ancak veritabanında depolanan içeriğe dayalı olarak her istek üzerine sayfa.

Her halükarda, bir uygulamanın kalıcı verilerinin çoğu bir veritabanında saklansa da, her şeyi orada saklamamız gerektiği anlamına gelmez. Veritabanları ticaretimizin araçlarından sadece biridir. Mümkün olduğu kadar çok farklı aracı iyi kullanmayı öğrenmeliyiz.

Bir satır ile bir tablo kesinlikle yanlış bir şey yok.

Bu tasarımınızın bir parçasıysa, onu uygulamalısınız. Tabloya bir kimlik sütunu verin, benzersiz bir kısıtlama verin, ardından yalnızca tek bir değere izin vermek için bir sütun kısıtlaması ekleyin. Bu, kimsenin, tabloyu okuyan SQL ifadelerinde (anlaşılır şekilde) bir nerede cümlesi yoksa felaket olabilecek ikinci bir satır ekleyemeyeceğini garanti eder.

Çok sayıda sütun almaya başlarsanız, tabloyu daraltmaya ve bunun yerine yapılandırma öğesi başına bir satıra sahip olmaya cazip gelebilirsiniz. Bu en iyi fikir değildir çünkü tip güvenliğini ve doğrulamasını kaybedersiniz. Ayrıca, sizin için önemli olabilecek çoklu kiralama ile ileri uyumluluğunuzu kaybedersiniz . Daha iyi bir çözüm, varlıklarınızın gerçekte ne olduğunu yeniden düşünmek ve farklı varlıklar için ayrı tek satırlık tablolara sahip olmaktır.

Evet, sadece tek sıralı bir tablonun iyi olduğunu söylemiyorum, ama bunlardan birden fazlasını isteyebilmenizi öneririm.

STATIC_CONTENT adlı bir tablo oluşturabilir ve bir anahtarın yanı sıra içerik, etkin / etkin olmayan izleyiciler vb. İçin sütunlara sahip olabilirsiniz. Ardından, "AnaSayfa" anahtarıyla bir satır oluşturun ve ana sayfanıza o anahtarın statik içeriğini yükleyin ve görüntüler. Bu şekilde, başka statik içeriğiniz (sayfa, kişi sayfası vb.) Olduğunda, bu tabloya satır ekleyebilirsiniz.

Sadece tek sıralı bir masaya sahip olmakta yanlış bir şey yoktur. Belirli bir varlığın yalnızca bir örneğine sahipseniz, bunu temsil etmenin en doğal yolu bu olabilir.

Ancak rastgele bir satır seçmek yanlış ve kötüdür. Etki alanı mantığınız yalnızca tek bir satır bekliyorsa, aslında daha fazlası varsa, verilerde bir hata olduğu açıktır. Bu nedenle, veritabanına kimlerin veya neyin geçersiz veri yazdığını bulmalı ve bunu yapmasını engellemelisiniz! Veritabanına bağlı olarak, bunun ilk başta olmasını önlemek için tabloya bir kısıtlama ekleyebilirsiniz, örneğin, birincil anahtar olarak yalnızca belirli bir değere izin vermek.

Walter'a eklemek için ..

Özellik tablosu yapısı birden çok veri türüne izin vermelidir.

Fileds:
PropertyName
PropertyTextValue
PropertyDateValue
PropertyNumericValue
PropertyBoolValue

Bana bir seviye daha soyutlayabiliyormuşsun gibi geliyor. Sonunda bir "AnaSayfa" bir "Sayfa" dır. İhtiyacınız olan özelliklere sahip farklı sayfa türleriniz olabilir. Sitenizde bölümler varsa, muhtemelen bir "Ana Sayfa" ile aynı şekilde çalışabilecek bir "SectionHomePage" öğesine ihtiyacınız olacaktır.

Gereksinim, ana sayfada tam olarak beş fotoğraf, tam olarak üç makale ve kullanıcı tarafından manuel olarak kontrol edilen iki rastgele metin bloğu görüntülenmesi. Bunu veritabanında doğru şekilde nasıl modellersiniz?

Hadi böyle deneyelim. Özellikleri buna göre nasıl ayırabileceğinizi görmek için bir ArticlePage tablosu ekliyorum.

PAGES
Id
Title
Description

HOMEPAGES
PageId (FK)
PhotoListLimit
ArticleListLimit
TextBlockListLimit

ARTICLEPAGE
PageId (FK)
ArticleMainQuote
ArticleMainBody
ArticlePhoto1
ArticlePhoto2

Bu benim için iyi olurdu, büyük bir site için bile harika olurdu.