Tiêu chuẩn thực tế cho hồ sơ thông tin khách hàng [đóng]

Tôi hiện đang đánh giá một dự án mới tiềm năng liên quan đến việc tạo DB cho thông tin khách hàng điển hình (userid, pwd, họ và tên, email, địa chỉ, telfnr ...). Tại thời điểm này, các yêu cầu chỉ được xác định đại khái.

DB khách hàng được mong đợi trong O (hàng triệu) hồ sơ. Để tính toán một số số chính xác cho việc định cỡ DB và đánh giá các tùy chọn & kiến ​​trúc DB tiềm năng, tôi đang tìm kiếm một số tiêu chuẩn thực tế cho các loại hồ sơ này. Đặc biệt, kích thước tiêu chuẩn của mọi lĩnh vực (tên, họ, địa chỉ, ...) hoặc avg điển hình cho một hồ sơ khách hàng đơn giản sẽ là thông tin tuyệt vời .

Với rất nhiều trang web thương mại điện tử ngoài kia, cần có một số loại cấu hình điển hình có thể được sử dụng lại và tránh phát minh lại bánh xe.

Có ý kiến ​​gì không?

---- biên tập ----

Các câu trả lời dường như đang hướng đến việc áp dụng một hồ sơ khách hàng tiêu chuẩn so với thiết kế của riêng bạn. Tôi muốn nhấn mạnh rằng trọng tâm của câu hỏi này là tìm một tài liệu tham khảo về kích thước trường cho đối tượng khách hàng và tránh tự mình tìm ra điều đó. (Tôi đã nhấn mạnh phần đó trên văn bản gốc - hiện được in đậm -)

Điều tốt đẹp về các tiêu chuẩn là bạn có rất nhiều để lựa chọn. - Andrew Stuart Tanenbaum

Những thứ như thế này rất cụ thể đối với khách hàng và ngành công nghiệp, mọi thứ chung chung sẽ bao gồm mọi thứ và bồn rửa trong nhà bếp. Đặc biệt là các định dạng loại EDI, chúng được xác định hữu cơ trong một thập kỷ trở lên trong hầu hết các trường hợp và bao gồm mọi thứ mà mọi công ty trong ủy ban từng muốn. Chúng được cho là chung chung trong ngành, và chúng trở nên cực kỳ đặc thù của ngành và cực kỳ dễ vỡ.

Không có con đường hoàng gia đến thiết kế hoặc thông tin bạn muốn. Làm thời gian và nỗ lực để có được các yêu cầu và có được một ước tính cụ thể. Nếu không bạn sẽ sai nhiều hơn đúng. Cách duy nhất để biết những gì bạn cần biết là đặt câu hỏi và tự mình tìm ra.

Nhiều hệ thống CRM sử dụng mẫu hiện được gọi là mẫu đối tượng Expando, trước đây được gọi là mẫu thuộc tính động . Nó về cơ bản là một cấu trúc từ điển cặp giá trị quan trọng. Ngoại trừ những trường hợp rất đặc biệt, nó được coi là một mẫu chống thiết kế và nên tránh.

Tôi đã thiết kế và xây dựng ít nhất 8 giải pháp CRM tùy chỉnh trong 20 năm qua, mỗi giải pháp đều có các yêu cầu khác nhau và không có mô hình dữ liệu nào (logic hoặc vật lý) sẽ hoạt động trên bảng cho tất cả các miền.

Giải pháp cụ thể cho các trường hợp cụ thể sẽ luôn được thiết kế tốt hơn.

Có một luồng trong ngăn xếp DBA về các thực tiễn tốt nhất cho các trường phổ biến thảo luận về các vấn đề. Nó rất quan trọng với những gì bạn dự định làm với dữ liệu và mức độ kỹ lưỡng của bạn. Nếu bạn thực sự cần hỗ trợ tất cả các địa chỉ email hợp lệ hoặc tất cả các tên hợp lệ, các cột của bạn sẽ cần lớn hơn nhiều so với việc bạn chỉ muốn hỗ trợ bất cứ điều gì tổ chức và ứng dụng của bạn xem xét một tập hợp con hợp lý của các giá trị hợp lệ.

Như Jarrod đã chỉ ra, nếu bạn tuân theo một tiêu chuẩn chung, bạn chắc chắn sẽ kết thúc với một định dạng hồ sơ bao gồm rất nhiều thứ mà hệ thống của bạn sẽ không bao giờ cần. Vì bạn đã biết rằng sẽ có một số lượng hồ sơ khá lớn, có khả năng bạn sẽ gặp các sự cố hiệu suất không cần thiết vì bạn đang hỗ trợ dữ liệu sẽ không bao giờ được sử dụng. Ngược lại, cũng có khả năng tiêu chuẩn sẽ không bao gồm các lĩnh vực mà bạn cần, đây sẽ là một vấn đề khó giải quyết; hoặc bạn phá vỡ tiêu chuẩn bằng cách thêm các trường này hoặc bạn sẽ phải tìm một số cách (có thể là vụng về) bao gồm các trường không chuẩn trong tiêu chuẩn.

Tôi nghĩ rằng vấn đề thực sự ở đây không phải là tìm kiếm một tiêu chuẩn phù hợp với một kích thước (mà hầu như sẽ luôn luôn là một kích cỡ phù hợp với NONE) mà là bạn đã được giao nhiệm vụ ước tính một giải pháp trong đó các yêu cầu không có quy định chưa. Trong những trường hợp này, tôi nghĩ rằng điều chuyên nghiệp duy nhất cần làm là ước tính tối thiểu dựa trên các yêu cầu bạn có, và sau đó ước tính tối đa dựa trên tất cả các yêu cầu không xác định có thể có mà bạn nghĩ có thể đưa ra. Chắc chắn, ước tính có thể trở nên thô sơ một cách lố bịch, trong trường hợp đó bạn nên giải thích cho bất cứ ai giao nhiệm vụ cho bạn, rằng việc đưa ra ước tính tốt cho đến khi các yêu cầu được xác định rõ hơn là không khả thi.

Tiêu chuẩn quốc tế hiện có

Có khá nhiều tiêu chuẩn, nhưng cụ thể cho các lĩnh vực nhất định, với các yêu cầu khác nhau cho từng lĩnh vực tùy thuộc vào nhu cầu thu thập dữ liệu của họ.

Chẳng hạn, nhưng không giới hạn (và nói từ kinh nghiệm với cả hai điều này):

• Phần mềm xử lý dữ liệu bệnh nhân và hồ sơ bệnh án nếu bạn dự định được chứng nhận cho một số thông số kỹ thuật nhất định.
  • Tiêu chuẩn dữ liệu thống nhất để nắm bắt thông tin hồ sơ y tế của bệnh nhân tại điểm chăm sóc (trình bày danh sách các tiêu chuẩn khác nhau cho hồ sơ y tế)
• Hồ sơ y tế Eletronic và các tiêu chuẩn kỹ thuật của họ

• lĩnh vực rộng hơn của Hồ sơ sức khỏe điện tử và các tiêu chuẩn kỹ thuật của họ

• phần mềm xử lý các bản ghi dữ liệu cuộc gọi và dữ liệu dịch vụ của nhà khai thác di động (không chính xác như một tiêu chuẩn, nhưng cho khả năng tương tác giữa các mạng đối tác).

Một số liên kết ở trên với các tài liệu khá chi tiết, liệt kê các yêu cầu về sức khỏe và định dạng của các trường (ví dụ, HL7 sử dụng các loại dữ liệu được xác định rõ ). Nhiều người trong số họ không đi vào chi tiết này mặc dù.

Tiêu chuẩn của chính phủ cho hồ sơ nội bộ

Chính phủ, quốc gia hoặc địa phương, thường có nhu cầu mạnh mẽ để ghi lại và lưu trữ thông tin cá nhân cho các cơ quan công cộng, và rõ ràng đã đưa ra "tiêu chuẩn" riêng mà họ thực hiện trên các tổ chức của mình (với mức độ thành công và khả năng tương tác khác nhau với các tổ chức đối tác) .

Một ví dụ có thể là Định dạng dữ liệu cho Tiêu chuẩn hồ sơ nhận dạng từ Chính phủ New Zealand.

Tiêu chuẩn khử yếu tố trong phần mềm

Bạn có thể lấy cảm hứng từ những thứ này hoặc sử dụng nguồn phần mềm CRM nguồn mở đã biết để sử dụng làm hướng dẫn và hướng dẫn tốt nhất cho thông số kỹ thuật dữ liệu của dữ liệu khách hàng của bạn.

Xem danh sách 10 Phần mềm CRM dành cho doanh nghiệp và xã hội nguồn mở hàng đầu mà bạn có thể tự mình tìm kiếm các mô hình dữ liệu của họ.

Tôi muốn nói rằng bạn cần tìm tiêu chuẩn cho các hệ thống EDI . Có hàng trăm tài liệu 'tiêu chuẩn', vì vậy bạn cần chọn một tài liệu dựa trên yêu cầu của bạn. Ví dụ: đây là định dạng cho hóa đơn TradACOMS mà bạn có thể lấy các trường bạn muốn từ đó.

Các mở ứng dụng Nhóm xuất bản một tập hợp các tiêu chuẩn mở để thực hiện ứng dụng và khả năng tương tác. Chúng chủ yếu theo định hướng XML, nhưng chúng chỉ định một hồ sơ khách hàng tiêu chuẩn với các trường và kích thước riêng lẻ (tìm CustomerPartyMastertrong danh sách tiêu chuẩn tài liệu).

Tôi sẽ nói "Bạn sẽ không cần nó (chưa)". Và với Ron Jeffries: "Luôn thực hiện mọi thứ khi bạn thực sự cần chúng, không bao giờ khi bạn thấy trước rằng bạn cần chúng."

Vì vậy, có lẽ nếu đến lúc phải thêm một cơ sở dữ liệu cụ thể vào dự án, bạn có nhiều kiến ​​thức hơn về dữ liệu sẽ được lưu trữ ở đó.