PHP Web Application: MySQL veritabanı tasarımı en iyi uygulamaları soru

7 Cevap php

Ben yaratmaya çalıştığımız bir PHP web uygulaması veritabanı tasarımı ile ilgili en iyi uygulamalar hakkında bir arkadaşı ile bir tartışmada şu anda duyuyorum. Uygulama işletmeler için tasarlanmış, ve imzalar her şirketin uygulamasını kullanarak birden fazla kullanıcıya sahip olacaktır.

Benim tasarım metodolojisi bulguları her şirket için yeni bir veri tabanı oluşturmaktır. Bu şekilde her şey kum-kutulu, modüler ve küçük. Benim arkadaşları felsefesi tek bir veritabanında herkesi koymaktır. Onun argümanı biz 1000 + şirketleri kaydolmak varsa, biz uğraşmak 1000 + veritabanları ile rüzgar olmasıdır. İş Zekası yapıyor olur karışıklık cabası.

Örneğin uğruna, uygulama bir sipariş giriş sistemi olduğunu varsayalım. Her şirket 100 + siparişleri bir gün yapıyor olsa bile ayrı veritabanları ile, tablo boyutu yönetilebilir kalabilir. Tek kova uygulamasında, tablo çok hızlı bir şekilde çok büyük alabilirsiniz.

Bunun için en iyi yöntem var mı? Ben web etrafında avcılık çalıştı, ama pek başarılı olmadı. Bağlantılar, whitepaper'lar ve sunumlar hoş geldiniz.

Teşekkür peşin,

The1Rob

7 Cevap

Ben, wordpress.com dan veritabanı mimar WordPress için barındırma hizmeti konuştuk. O da hep birlikte müşterilerine hosting, tek bir veritabanı ile başladığını söyledi. Tek bir blog sitesinin içeriği gerçekten sonra, o kadar değil. Bu tek bir veritabanı daha yönetilebilir olduğunu nedenle duruyor.

Onlar yüzlerce ve binlerce müşteri var bu onlar için de işe yaramadı, onlar birden çok fiziksel sunucuları çalıştıran ve her sunucuda müşterilerinin bir alt kümesini hosting, scale out için gerekli olduğunu fark etti. Onlar bir sunucu eklediğinizde, bir bireysel müşteri bloga ait tek bir veritabanı içinde veri ayırmak için yeni bir sunucuya bireysel müşterilerin göç etmek kolay, ama zor olurdu.

Müşterilerin gelir ve gider, ve diğerleri bayat devam ederken, bazı müşterilerinin bloglar yüksek hacimli aktiviteye sahip olarak, çoklu sunucular üzerinde dengelenme daha da karmaşık bakım iş olur. İzleme boyutu ve bireysel veritabanı başına aktivite çok daha kolaydır.

Aynı şekilde backup or restore veri terrabytes içeren tek bir veritabanı bir veritabanı yapıyor, tek tek veritabanı yedekleme ve bir kaç megabayt her geri yüklemeler karşı, önemli bir faktördür. Bir müşteri aramaları ve kendi veri nedeniyle bazı kötü veri girişi için SNAFU'd var diyor ve dünkü yedekten veri geri lütfen olabilir: düşünün? Tüm müşterilerinin tek bir veritabanını paylaşan olmadığını nasıl one müşterinin verileri geri yüklemek istiyorsunuz?

Sonunda onlar, yönetmek karmaşık olsa da, bir separate database per customer içine yarma karar onlara daha fazla esneklik sundu ve bu model kendi hosting hizmetini yeniden tasarlandı.

Yani, bir data modeling perspektifinden bu veri hacmi belli bir kesme noktası geçmek gibi bazı database administration görevleri daha kolay hale, tek bir veritabanında her şeyi tutmak için yapılacak en doğru şey gibi görünüyor süre.

Ben her şirket için yeni bir veritabanı oluşturmak asla. Eğer modüler bir tasarım istiyorsanız, tabloları kullanarak bu oluşturmak ve düzgün birincil ve ikincil anahtarları bağladı. I database normalization öğrendi yerdir ve ben burada size yardımcı olacaktır eminim.

Bu koyardım yöntemdir. SQL Article

Ben şahsen bu durumu ele değil, ama iş zekası yapmak istiyorsanız, o zaman sen üzerinde istediğiniz herhangi bir analiz çalıştırabilirsiniz çevrimdışı bir veritabanına veri toplamak gerektiğini düşünürdüm.

Ayrıca, ayrı veritabanlarında tutarak daha kolay çoğaltma teknolojileri dağınık başvurmadan (büyük olasılıkla 1000 + müşteri varsa yapmak zorunda olacak) sunucuları arasında bölümlemek yapar.

Ben bir süre önce benzer bir soru vardı ve tek bir veritabanı ölçüde daha yönetilebilir olduğu sonucuna geldi. Şu anda, biz (yaklaşık 10), birden fazla veritabanı var ve zaten biz kod yükseltme özellikle yönetmek için bir ağrı oluyor. Biz her veritabanı geçirmek zorunda.

Ters veriler temiz ayrılmış olmasıdır. Nedeniyle bizim veri hassasiyeti, bu iyi bir şey, ama bu biraz daha zor yetişmek için yapar.

Bu sizin şemalar değiştirmek için ne kadar büyük olasılıkla bağlıdır. Onlar hiç değiştirmek varsa, güvenle 1000 ayrı veritabanlarına bu değişiklikleri yapmak mümkün olacak? Bir ölçeklenebilirlik sorun tasarımı ile bulunursa, nasıl 1000 veritabanları için bunu düzeltmek için gidiyoruz?

Biz müşterilerin çok sayıda bir SaaS (Software-as-a-Service) iş çalıştırmak ve aynı veritabanındaki tüm müşterileri tutmak için seçmişlerdir. Ayrı veri tabanını 1000 yönetme operasyonel bir kabus.

Eğer veri modeli ve onlara erişmek iş nesneleri / raporlama sorguları oluşturmak çok çalışkan olmak zorunda. Eğer düşünebilirsiniz bir yaklaşım, her tablonun şirket kimliği taşımak ve sağlamak olduğunu fıkra şu anda oturum açmış kullanıcı için şirket kimliği içerir NEREDE her. Bir veri erişim katmanı kullanıyorsanız, oradaki durum zorlayabilir.

Eğer büyük büyüdükçe, yine dikey örneğin, her bir fiziksel sunucu üzerinde şirketlerin grupları yerleştirerek bölümlendirebilirsiniz Sunucu A, sunucu b önümüzdeki 100 şirketleri ilk 100 şirket

Ben co-işçi ile aynı fikirde olurdu. İlişkisel veritabanları büyük miktarda veri işlemek için tasarlanmış, ve (1000 + şirketler, şirket başına birden fazla kullanıcı, 100 + siparişler / gün) bahsediyoruz numaraları beklenen sınırları içinde iyi vardır. Ayrı veritabanları demektir:

  • her komut dosyası (bellek ve hız cezası) çoklu veritabanı bağlantıları
  • bakım zordur (DB sistemleri genellikle bir grup olarak veritabanları üzerinde hareket için araçlar vermeyin) yani şema değişiklikleri, yedekleme, ve benzeri görevleri daha zor olacak
  • birden fazla firmanın veri sorguları çalıştırmak için zor

Siteniz büyük olursa, sonunda birden çok sunucu arasında veri dağıtmak için gerekebilir. Deal with that when it happens. performans nedenleriyle bu şekilde işe başlamak için erken optimizasyonu gibi geliyor.