Standar de-facto untuk catatan informasi pelanggan [ditutup]

Saat ini saya sedang mengevaluasi proyek baru yang potensial yang melibatkan pembuatan DB untuk informasi pelanggan yang khas (userid, pwd, nama depan & belakang, email, alamat, telfnr ...). Pada titik ini, persyaratan hanya didefinisikan secara kasar.

DB pelanggan diharapkan dalam O (jutaan) catatan. Untuk menghitung beberapa nomor back-of-the-envelope untuk ukuran DB dan mengevaluasi opsi & arsitektur DB potensial, saya mencari beberapa standar de-facto untuk jenis catatan ini. Khususnya, ukuran std dari setiap bidang (nama depan, nama belakang, alamat, ...) atau rata-rata rata-rata untuk catatan pelanggan yang sederhana akan menjadi info hebat .

Dengan begitu banyak situs web e-commerce di luar sana, harus ada semacam konfigurasi khas yang dapat digunakan kembali dan menghindari menciptakan kembali roda.

Ada ide?

---- edit ----

Jawabannya tampaknya mengarah ke mengadopsi catatan pelanggan standar vs mendesain sendiri. Saya ingin menekankan bahwa fokus dari pertanyaan ini adalah untuk menemukan referensi ukuran bidang untuk objek pelanggan, dan menghindari mencari tahu sendiri. (Saya telah menekankan bagian itu pada teks asli - sekarang dicetak tebal -)

Yang menyenangkan tentang standar adalah Anda memiliki begitu banyak pilihan. - Andrew Stuart Tanenbaum

Hal-hal seperti ini sangat spesifik untuk pelanggan dan industri, generik apa pun akan mencakup semuanya dan wastafel dapur. Terutama format tipe EDI, mereka didefinisikan secara organik lebih dari satu dekade atau lebih dalam banyak kasus dan mencakup semua yang diinginkan setiap perusahaan dalam komite. Mereka seharusnya generik industri, dan mereka menjadi sangat spesifik industri dan sangat rapuh.

Tidak ada jalan kerajaan ke desain atau informasi yang Anda inginkan. Lakukan waktu dan upaya untuk mendapatkan persyaratan dan dapatkan estimasi yang konkret. Kalau tidak, Anda akan lebih salah daripada benar. Satu-satunya cara untuk mengetahui apa yang perlu Anda ketahui adalah dengan mengajukan pertanyaan dan mencari tahu sendiri.

Banyak sistem CRM menggunakan apa yang sekarang disebut pola objek Expando, yang sebelumnya dikenal sebagai pola properti dinamis . Ini pada dasarnya adalah pasangan kunci membangun kamus nilai. Kecuali untuk kasus yang sangat khusus itu dianggap sebagai Anti-Pola desain dan harus dihindari.

Saya telah merancang dan membangun setidaknya 8 solusi CRM khusus dalam 20 tahun terakhir, masing-masing dan setiap orang memiliki persyaratan yang berbeda dan tidak ada model data (logis atau fisik) yang akan bekerja secara menyeluruh untuk semua domain.

Solusi spesifik untuk kasus spesifik akan selalu menjadi desain yang lebih baik.

Ada utas dalam tumpukan DBA tentang praktik terbaik untuk bidang orang biasa yang membahas masalah tersebut. Sangat penting apa yang Anda rencanakan untuk dilakukan dengan data dan seberapa menyeluruh Anda perlu. Jika Anda benar-benar perlu mendukung semua alamat email yang valid atau semua nama yang valid, kolom Anda harus jauh lebih besar daripada jika Anda hanya ingin mendukung apa pun yang organisasi dan aplikasi Anda anggap sebagai subset wajar dari nilai yang valid.

Seperti yang ditunjukkan Jarrod, jika Anda mengikuti standar generik, Anda pasti akan berakhir dengan format rekaman yang mencakup banyak hal yang tidak akan diperlukan oleh sistem Anda. Karena Anda sudah tahu bahwa akan ada sejumlah besar catatan, kemungkinan Anda akan mendapatkan masalah kinerja yang tidak perlu karena Anda mendukung data yang tidak akan pernah digunakan. Sebaliknya, kemungkinan standar tidak akan mencakup bidang yang Anda butuhkan, yang akan menjadi masalah yang sulit untuk dipecahkan; baik Anda melanggar standar dengan menambahkan bidang ini, atau Anda harus menemukan beberapa (mungkin kikuk) cara memasukkan bidang non-standar dalam standar.

Saya pikir masalah sebenarnya di sini bukan tentang menemukan standar satu ukuran untuk semua (yang hampir selalu akan menjadi satu ukuran untuk TIDAK ADA) tetapi Anda telah ditugaskan untuk memperkirakan solusi di mana persyaratannya tidak ditentukan belum. Dalam kasus ini, saya pikir satu-satunya hal profesional yang harus dilakukan adalah membuat estimasi minimum berdasarkan persyaratan yang Anda miliki, dan kemudian membuat estimasi maksimum berdasarkan semua persyaratan yang mungkin tidak ditentukan yang menurut Anda mungkin muncul. Tentu saja, perkiraan tersebut mungkin menjadi sangat kasar, dalam hal ini Anda harus menjelaskan kepada siapa pun yang menugasi Anda dengan hal ini, bahwa hanya tidak layak untuk membuat perkiraan yang baik sampai persyaratan lebih jelas.

Standar Internasional yang ada

Ada beberapa standar, tetapi khusus untuk bidang tertentu, dengan persyaratan yang berbeda untuk masing-masing tergantung pada kebutuhan pengumpulan data mereka.

Misalnya, tetapi tidak terbatas pada (dan berbicara dari pengalaman dengan keduanya):

• Perangkat lunak yang menangani data pasien dan catatan medis jika Anda berencana untuk disertifikasi untuk spesifikasi tertentu.
  • Standar Data yang Seragam untuk Menangkap Informasi Rekam Medis Pasien di Tempat Perawatan (menyajikan daftar standar yang berbeda untuk catatan medis)
• Rekam Medis Eletronic dan Standar Teknisnya

• bidang yang lebih luas dari Catatan Kesehatan Elektronik dan Standar Teknis mereka

• perangkat lunak yang berurusan dengan catatan data panggilan operator seluler dan catatan data layanan (tidak persis seperti standar, tetapi untuk interoperabilitas antara jaringan mitra).

Beberapa tautan di atas ke dokumen yang cukup terperinci, mendaftar bahkan persyaratan untuk kesehatan dan pemformatan bidang (misalnya, HL7 menggunakan tipe data yang terdefinisi dengan baik ). Pada banyak dari mereka tidak masuk dalam detail sebanyak ini.

Standar yang Didorong Pemerintah untuk Catatan Internal

Pemerintah, nasional atau lokal, seringkali memiliki kebutuhan kuat untuk mencatat dan menyimpan informasi pribadi untuk kantor publik, dan jelas telah muncul dengan "standar" sendiri, yang mereka terapkan di seluruh organisasi mereka (dengan berbagai tingkat keberhasilan dan interoperabilitas dengan organisasi mitra) .

Contohnya adalah Format Data untuk Identitas Catatan Standar ini dari Pemerintah Selandia Baru.

Standar De-Facto dalam Perangkat Lunak

Anda bisa mengambil inspirasi dari ini, atau menggunakan sumber perangkat lunak CRM open-source yang dikenal untuk digunakan sebagai praktik terbaik dan pedoman untuk spesifikasi data data pelanggan Anda.

Lihat daftar Top 10 Sumber Terbuka Bisnis dan Perangkat Lunak CRM Sosial , di mana Anda dapat melihat sendiri model data mereka.

Saya akan mengatakan Anda perlu menemukan standar untuk sistem EDI . Ada ratusan dokumen 'standar', jadi Anda harus memilih satu berdasarkan kebutuhan Anda. Misalnya, berikut adalah format untuk faktur TRADACOMS yang dapat Anda ambil bidangnya.

The Buka Aplikasi Grup menerbitkan satu set standar terbuka untuk implementasi aplikasi dan interoperabilitas. Mereka sebagian besar berorientasi XML, tetapi mereka menentukan catatan pelanggan standar dengan masing-masing bidang dan ukuran (lihat CustomerPartyMasterdi daftar standar dokumen).

Saya akan mengatakan "Anda tidak akan membutuhkannya (belum)". Dan dengan Ron Jeffries: "Selalu laksanakan hal-hal ketika Anda benar-benar membutuhkannya, jangan pernah ketika Anda hanya meramalkan bahwa Anda membutuhkannya."

Jadi mungkin jika sekarang saatnya untuk menambahkan database konkret ke proyek Anda memiliki lebih banyak pengetahuan tentang data yang akan disimpan di sana.