Müşteri bilgi kaydı için fiili standartlar [kapalı]

Şu anda tipik müşteri bilgileri (userid, pwd, ad ve soyadı, e-posta, adres, telfnr ...) için bir DB oluşturmayı içeren potansiyel yeni bir projeyi değerlendiriyorum. Bu noktada gereksinimler sadece kabaca tanımlanır.

Müşteri DB'sinin O (milyon) kayıtlarında olması bekleniyor. DB boyutlandırma için bazı zarf arkası sayılarını hesaplamak ve potansiyel DB seçenekleri ve mimarilerini değerlendirmek için, bu tür kayıtlar için bazı fiili standartlar arıyorum. Özellikle, her alanın standart adı (ad, soyadı, adres, ...) veya basit bir müşteri kaydı için tipik ortalama büyük bilgi olurdu .

Orada çok fazla e-ticaret web sitesi ile, yeniden kullanılabilir ve tekerleği yeniden icat kaçınmak bir tür tipik yapılandırma olmalıdır.

Herhangi bir fikir?

---- Düzenle ----

Cevaplar, kendi tasarımınızı oluşturmaya karşı standart bir müşteri kaydını benimsemeye yöneliyor gibi görünüyor. Bu sorunun odağı bir bulmak olduğunu ben strese istiyorum başvuru müşteri nesnesi için saha boyutlandırma için ve önlemek başına da out endam (O orijinal metin üzerinde parça vurguladı ettik -. Kalın şimdi -)

Standartlar hakkında güzel bir şey, aralarından seçim yapabileceğiniz çok şey var. - Andrew Stuart Tanenbaum

Bunun gibi şeyler bir müşteriye ve sektöre çok özeldir, jenerik her şey her şeyi ve mutfak lavabosunu içerecektir. Özellikle EDI tipi formatlar, on yıl veya daha fazla bir süre boyunca organik olarak tanımlandılar ve komitedeki her şirketin istediği her şeyi dahil ettiler. Endüstrinin jenerik olması gerekiyordu ve endüstriye özgü ve son derece kırılgan hale geldiler.

İstediğiniz tasarıma veya bilgiye kraliyet yolu yoktur. Gereksinimleri elde etmek ve somut bir tahmin almak için zaman ve çaba gösterin. Aksi takdirde düzeltmekten daha yanlış olursunuz. Bilmeniz gerekeni bilmenin tek yolu soruları sormak ve kendiniz çözmektir.

Birçok CRM sistemi, daha önce dinamik özellik deseni olarak bilinen Expando nesne kalıbı olarak adlandırılan şeyi kullanır . Temelde anahtar değer çifti sözlük yapısıdır. Çok özel durumlar dışında bir tasarım Anti-Pattern olarak kabul edilir ve kaçınılmalıdır.

Son 20 yılda en az 8 özel CRM çözümü tasarladım ve inşa ettim, herkesin farklı gereksinimleri vardı ve veri modellerinin hiçbiri (mantıksal veya fiziksel) tüm alanlar için tahtada işe yaramazdı.

Özel durumlar için özel çözümler her zaman daha iyi tasarımlar olacaktır.

DBA yığınında , sorunları tartışan ortak kişi alanları için en iyi uygulamalar hakkında bir konu vardır. Verilerle ne yapmayı planladığınız ve ne kadar kapsamlı olmanız gerektiği çok önemlidir. Tüm geçerli e-posta adreslerini veya tüm geçerli adları desteklemeniz gerekiyorsa, sütunlarınızın yalnızca kuruluşunuz ve uygulamanızın geçerli değerlerin makul bir alt kümesini göz önünde bulundurmak istediklerini desteklemek istediğinizden çok daha büyük olması gerekir.

Jarrod'un belirttiği gibi, genel bir standardı takip ederseniz, kesinlikle sisteminizin asla ihtiyaç duymayacağı birçok şeyi içeren bir kayıt formatı elde edersiniz. Oldukça fazla sayıda kayıt olacağını zaten bildiğiniz için, muhtemelen kullanılmayacak verileri desteklediğiniz için gereksiz performans sorunları yaşayabilirsiniz. Tersine, standardın ihtiyacınız olan alanları içermemesi de muhtemeldir, bu da çözülmesi acı verici bir problem olacaktır; ya bu alanları ekleyerek standardı ihlal edersiniz ya da standart dışı alanları standartlara dahil etmenin (muhtemelen tıknaz) bir yolunu bulmanız gerekir.

Bence buradaki asıl sorun, tek bedene uyan bir standart bulmakla ilgili değil (neredeyse her zaman tek bedene uyan bir NONE olacak), ancak gereksinimlerin karşılanmadığı bir çözümü tahmin etmekle görevlendirildiğinizi düşünüyorum. henüz belirtilmedi. Bu durumlarda, yapılacak tek profesyonel şey, sahip olduğunuz gereksinimlere göre minimum bir tahmin yapmak ve daha sonra ortaya çıkabileceğini düşündüğünüz tüm tanımlanmamış gereksinimlere göre maksimum bir tahmin yapmak olduğunu düşünüyorum. Tabii ki, tahmin gülünç derecede kaba hale gelebilir, bu durumda gereksinimler daha iyi tanımlanana kadar iyi bir tahmin yapmanın mümkün olmadığını, bu konuda size kim görev yaptığını açıklamanız gerekir.

Mevcut Uluslararası Standartlar

Veri toplama gereksinimlerine bağlı olarak her biri için değişen gereksinimlerle birlikte, bazı alanlara özgü oldukça az standart vardır.

Örneğin, bunlarla sınırlı olmamakla birlikte (ve bunların her ikisiyle ilgili deneyimlerden konuşmak):

• Belirli özellikler için sertifika almayı planlıyorsanız, hasta verileri ve tıbbi kayıtlarla ilgilenen yazılımlar .
  • Bakım Noktasında Hasta Tıbbi Kayıt Bilgilerini Yakalamak için Tekdüzen Veri Standartları (tıbbi kayıtlar için farklı standartların bir listesini sunar)
• Eletronic Tıbbi Kayıtları ve Teknik Standartları

• Elektronik Sağlık Kayıtlarının geniş alanı ve Teknik Standartları

• mobil operatörlerin çağrı veri kayıtlarını ve servis veri kayıtlarını ele alan yazılım (tam olarak standart olarak değil, ortak ağlar arasında birlikte çalışabilirlik için).

Yukarıdaki bazı bölümler, sağlık ve alanların biçimlendirilmesi için bile gereksinimleri listeleyen oldukça ayrıntılı belgelere bağlantı verir (örneğin, HL7 iyi tanımlanmış veri türlerini kullanır ). Birçoğu da bu kadar ayrıntılı gitmiyor.

Dahili Kayıtlar için Devlet Odaklı Standartlar

Ulusal veya yerel yönetimlerin, genellikle kamu ofisleri için kişisel bilgileri kaydetme ve saklama ihtiyacı vardır ve açık bir şekilde kendi kuruluşlarında uyguladıkları kendi "standartlarını" ortaya koymuşlardır (farklı düzeylerde başarı ve ortak kuruluşlarla birlikte çalışabilirlik ile). .

Buna bir örnek , Yeni Zelanda Hükümeti'nin Kimlik Kayıtları Standardı için bu Veri Formatları olabilir .

Yazılımda De-Facto Standartları

Bunlardan ilham alabilir veya müşteri verilerinizin veri spesifikasyonları için en iyi uygulamalar ve yönergeler olarak kullanmak üzere bilinen açık kaynaklı CRM yazılımının kaynağını kullanabilirsiniz.

Bkz Top 10 Açık Kaynak İş ve Sosyal CRM Yazılımı onların veri modellerini kendinize bakmak çıkması gereken liste.

EDI sistemleri için standartlar bulmanız gerektiğini söyleyebilirim . Yüzlerce 'standart' belge vardır, bu nedenle gereksinimlerinize göre bir tane seçmeniz gerekir. Örneğin, TRADACOMS faturası için , istediğiniz alanları alabileceğiniz bir biçim .

Açık Uygulamaları Grubu uygulama uygulanması ve birlikte işlerlik için açık standartlar kümesi yayınlar. Çoğunlukla XML yönelimlidirler, ancak ayrı alanlara ve boyutlara sahip standart bir müşteri kaydı belirtirler ( CustomerPartyMasterbelge standartları listesinde arayın ).

"Henüz ihtiyacın olmayacak" derdim. Ve Ron Jeffries ile: "Her zaman onlara gerçekten ihtiyacınız olduğunda uygulayın, asla onlara ihtiyacınız olduğunu asla öngörmediğinizde."

Belki de projeye somut bir veritabanı ekleme zamanı gelmişse, orada saklanacak veriler hakkında daha fazla bilgiye sahip olursunuz.