Kullanıcı ve kullanıcı profilini farklı tablolarda tut?

Geliştiricilerin temel kullanıcı bilgilerini bir tabloda (e-posta / kullanıcı adı, şifre karma adı, ekran adı) ve diğer gerekli olmayan kullanıcı profilinin bir diğerinde (oluşturma tarihi, ülke, vb.) Tutmayı tercih ettiği birkaç projede gördüm. Temel olmayan terimlerle bu verilere sadece ara sıra ihtiyaç duyulduğunu kastediyorum. Açıkçası yararı, eğer ORM'yi kullanıyorsanız, daha az alan sorgulamak elbette ki iyidir. Ancak, aynı tabloya eşlenmiş iki varlık olabilir ve bu, ihtiyaç duymadığınız şeyleri sorgulamanızı önler (daha kolay olurken). Bunları iki masada tutmanın başka bir avantajı bilen var mı?

Bu, projenizin boyutuna ve gereksinimlerine bağlıdır.

Kullanıcılar hakkındaki verilerin farklı amaçlarla ve böylece gerekliliklerle iki gruba ayrılmasının bir yolunu görebiliyorum:

• Kimlik verileri: kullanıcı adı, şifre hash, e-posta adresi, son giriş zamanı, vb.
• Kullanıcı tercihlerini, en son etkinlikleri, durum güncellemelerini vb. İçeren kullanıcı profili verileri.

Kullanıcıyla ilgili her iki kategoriye de düşebilecek bazı özellikler olduğunu unutmayın (örneğin, kullanıcının doğum tarihi). Bu iki set arasındaki fark, birincisinin sıkı bir şekilde kontrol edilmesidir ve yalnızca belirli iş akışları yoluyla değiştirilebilir. Örneğin, bir şifreyi değiştirmek mevcut şifreyi sağlamayı gerektirebilir, e-postayı değiştirmek e-postanın doğrulanmasını gerektirebilir ve kullanıcının şifreyi unutması durumunda kullanılır.

Tercihler, böyle bir ACL gerektirmez ve kullanıcı tarafından onaylandığı sürece, kullanıcı veya başka bir uygulama tarafından teorik olarak değiştirilebilir. Kötü amaçlı veya bir hata nedeniyle bir uygulama verileri bozarsa veya değiştirmeyi denerse (başka güvenlik önlemleri alındığını varsayarsak) bahis miktarı düşüktür. çünkü kullanıcının kimliğini almak veya hizmeti reddetmek veya yönetici için destek maliyetlerine vb. neden olmak için kullanılabilirler.

Bu nedenle, genellikle veriler iki tür sistemde depolanır:

• Kimlik verileri genellikle bir dizine veya bir IAM çözümüne gider.
• Tercih verileri bir veritabanında sona erecektir.

Uygulamada insanların bu kuralları ihlal edeceğini ve birini ya da diğerini kullanacağını (örneğin, ASP.NET üyelik sağlayıcısının arkasındaki SQL sunucusu) söylemiştik.

Kimlik verileri büyüdükçe veya onu kullanan kuruluş büyüdükçe, farklı sorun türleri ortaya çıkar. Örneğin, dizin durumunda, parola değişikliklerini hemen bir çok sunucu ortamındaki tüm sunuculara çoğaltmaya çalışır. Bununla birlikte, kullanıcı tercihi sadece nihai tutarlılık gerektirir. (FYI: Bunların her ikisi de CAPS teoreminin farklı optimizasyonlarıdır.)

Son olarak, dizinler (özellikle çevrimiçi / bulut dizinleri), OAUTH (örneğin, Facebook, Google, Microsoft Hesabı, ADFS gibi) protokollerini kullanan diğer kaynaklara erişim belirteçleri yayınlar; Bir veritabanı, dizinin gerekmeyen oldukça karmaşık birleştirmeleri ve sorgu yapısını destekleyecektir.

Daha fazla ayrıntı için, kimlik dizininde ve veritabanında yapılan birkaç arama yardımcı olacaktır.

Sonunda, herhangi bir üçüncü tarafla entegrasyon da dahil olmak üzere (ve ne kullanıyorlarsa), senaryolarınızın gelecekte ne olacağı ve ne olacağı beklenir. İyi bir proje ise ve kullanıcı kimliği verilerini güvence altına alabildiğinizden ve doğru şekilde doğrulayabildiğinizden eminseniz, veritabanına gidebilirsiniz. Aksi takdirde, bir kimlik rehberini araştırmaya değer olabilir.

DB, IMO'ya giderseniz, bir DB vs iki kullanmak sonunda hem kullanıcılar hem de uygulamalar için erişim kontrolüne iner.

Temel nitelikler için bir kişi tablosu ve bire-bir ilişki olan diğer özellikler için ikinci bir tablo olması durumunda en azından üç durum söz konusudur:

• Bir resim gibi BLOB veri . Ayrı bir tablo verinin performans nedenleriyle, örneğin ayrı bir tablo alanında ayrı ayrı depolanmasını sağlar.
• Herkese uygulanmayan veya yalnızca belirli bir rol oynayan bir kişi için geçerli olmayan veriler. Ana tablonun bir parçası olsaydı, birçok satırda boş olacak sütunlar olarak düşünün. Bir kliniğin veritabanında, bir kişi tablosu, bir hasta tablosu ve bir tıbbi tablo olabilir, ilki temel özelliklere sahip olacaksınız, ikincisi yalnızca kişi sigorta kapsamındaki bir hasta olduğunda ilgili niteliklere sahip olabilir. üçüncü tablo (kişi doktor olduğunda) tıbbi uzmanlığa ve yalnızca tıbbi personel için geçerli olan diğer bilgilere sahip olabilirsiniz. Açıkçası bir doktor hasta olabilir.
• Uzak bir sistemdeki bir varlık ile ilişkiyi gerçekleştiren bir tablo. Bu durumda, tablo birlikte çalışabilirlik nedenleriyle ayrı tanımlayıcılarda benzersiz tanımlayıcılar arasında bir denklik oluşturur.

Bence, ortaya çıkardığınız dava ikinci davaya uyuyor.

Onları ayrı tutmamın ana nedeni, Nesne Yönelimli programlamada 'tanrı sınıfı' olarak bilinen şeyi denemek ve kaçınmak. ORM'ler tabloları ve alanları sınıflar ve niteliklerle ilişkilendirir, bu yüzden de SQL seviyesiyle alakalı hale gelir (bir ORM olmasa bile, genellikle oyunda benzer bir ilke vardır).

Kullanıcı sınıfı (ve kullanıcı tablosu ilişkilendirilerek) sık sık tanrı sınıfı haline gelen yüzlerce öznitelik / alan, düzinelerce veya yüzlerce yöntem ve 1000'den fazla satırlık bir sınıf tanımı (yöntem için) olan tablodur. Hepsini gördüm. Birden fazla.

Böylece, kullanıcıdan ayrılma buna hitap etmeye çalışır. Kişi, kullanıcı, hesap olabilir ve endişelerin ayrılması biraz yapay görünebilir ancak karmaşıklığı önlemek ve önlemek ve her bir nesnenin verilerin yalnızca bir yönü ile ilgilenmesini sağlamaktır.