고객 정보 기록에 대한 사실상의 표준 [폐쇄]

현재 일반적인 고객 정보 (사용자 ID, 비밀번호, 이름, 성, 이메일, 주소, telfnr ...)에 대한 DB를 만드는 잠재적 인 새 프로젝트를 평가하고 있습니다. 이 시점에서 요구 사항은 대략적으로 만 정의됩니다.

고객 DB는 수백만 레코드로 예상됩니다. DB 사이징을위한 일부 Back-of-Envelope 수를 계산하고 잠재적 인 DB 옵션 및 아키텍처를 평가하기 위해 이러한 종류의 레코드에 대한 사실상의 표준을 찾고 있습니다. 특히 간단한 고객 레코드에 대한 모든 필드의 표준 크기 (이름, 성, 주소 등) 또는 일반적인 평균은 큰 정보가 됩니다.

전자 상거래 웹 사이트가 너무 많으면 재사용 할 수있는 일반적인 구성이 있어야하며 휠을 다시 발명하지 않아도됩니다.

어떤 아이디어?

---- 편집하다 ----

답변은 표준 고객 레코드를 채택하고 자신을 설계하는쪽으로 나아가고있는 것 같습니다. 이 질문의 초점이 찾을 것을 나는 스트레스 싶습니다 참조 고객 객체의 필드 크기에 대한, 그리고 피하기는 내 자신이 아웃 파악 (나는 원래 텍스트에 대한 부분을 강조했습니다 -. 굵은 글씨로 지금 -)

표준에 대한 좋은 점은 선택할 수있는 것이 너무 많다는 것입니다. - 앤드류 스튜어트 타넨 바움

이와 같은 것들은 고객과 산업에 따라 매우 다르며 일반적인 것에는 모든 것과 부엌 싱크대가 포함됩니다. 특히 EDI 형식 형식은 대부분의 경우 10 년 이상 유기적으로 정의되었으며위원회의 모든 회사가 원했던 모든 것을 포함합니다. 그들은 산업 전반에 속해야했고, 산업에 특화되어 있고 취하기가 쉬워졌습니다.

원하는 디자인이나 정보로가는 길은 없습니다. 요구 사항을 파악하고 구체적인 견적을 얻으려면 시간과 노력을 기울이십시오. 그렇지 않으면 당신은 올바른 것보다 더 틀릴 것입니다. 알아야 할 것을 아는 유일한 방법은 질문을하고 스스로 알아내는 것입니다.

많은 CRM 시스템은 이전에 동적 속성 패턴 으로 알려진 Expando 개체 패턴을 사용 합니다. 기본적으로 키 값 쌍 사전 구성입니다. 매우 특별한 경우를 제외하고는 안티 패턴 디자인으로 간주되므로 피해야합니다.

나는 한 설계 및 구축 적어도 8 개 사용자 정의 CRM 솔루션을 지난 20 년 동안, 각각 모두가 서로 다른 요구 사항이 있고 (논리적 또는 물리적) 데이터 모델 중 어느 것도 모든 도메인에 대해 전반적으로 일하지 것이다.

특정 사례에 대한 특정 솔루션은 항상 더 나은 디자인이 될 것입니다.

DBA 스택 에는 문제를 논의하는 일반적인 개인 필드에 대한 모범 사례에 대한 스레드 가 있습니다. 데이터로 무엇을하려고하는지, 얼마나 철저해야하는지가 중요합니다. 실제로 모든 유효한 전자 메일 주소 또는 모든 유효한 이름을 지원해야하는 경우 조직 및 응용 프로그램이 유효한 값의 합리적인 하위 집합을 고려하는 것만 지원하려는 경우보다 열이 훨씬 커야합니다.

Jarrod가 지적했듯이 일반적인 표준을 따르면 시스템에서 절대 필요하지 않은 많은 것들을 포함하는 레코드 형식으로 끝날 것입니다. 상당히 많은 레코드가 있다는 것을 이미 알고 있으므로 사용하지 않는 데이터를 지원하기 때문에 불필요한 성능 문제가 발생할 수 있습니다. 반대로, 표준에 필요한 필드가 포함되어 있지 않아서 해결하기 어려운 문제가 될 수 있습니다. 이 필드를 추가하여 표준을 어기거나 표준 내에 비표준 필드를 포함하는 (아마도 어색한) 방법을 찾아야합니다.

여기에서 실제 문제는 모든 크기의 표준을 찾는 것이 아니라 (거의 항상 하나의 크기에 적합하지 않음) 요구 사항이 아닌 솔루션을 추정해야 할 과제라고 생각합니다. 아직 지정되었습니다. 이 경우, 내가해야 할 유일한 요구 사항은 요구 사항을 기반으로 최소 추정을 한 다음 발생할 수 있다고 생각되는 모든 정의되지 않은 요구 사항을 기반으로 최대 추정을하는 것입니다. 확실히, 추정치가 엄청나게 거칠어 질 수 있습니다.이 경우,이를 수행 한 사람에게 설명해야합니다. 요구 사항이보다 명확하게 정의 될 때까지는 제대로 추정 할 수 없습니다.

기존 국제 표준

데이터 수집 요구 사항에 따라 각 표준에 대한 요구 사항이 다르지만 특정 필드에 따라 상당히 많은 표준이 있습니다.

예를 들어 (이 두 가지에 대한 경험을 통해 이야기하는 경우) :

• 특정 사양에 대한 인증을 계획중인 경우 환자 데이터 및 의료 기록을 처리하는 소프트웨어 .
  • 치료 시점에서 환자의 의료 기록 정보를 캡처하기위한 균일 한 데이터 표준 (의료 기록에 대한 다양한 표준 목록 제공)
• Eletronic 의료 기록 및 기술 표준

• 더 넓은 전자 건강 기록 분야 및 기술 표준

• 이동 통신사의 통화 데이터 레코드 및 서비스 데이터 레코드를 처리하는 소프트웨어 (정확히 표준이 아니라 파트너 네트워크 간의 상호 운용성을 위해).

위의 일부는 상당히 상세한 문서에 연결되어 필드의 건강 및 서식에 대한 요구 사항도 나열합니다 (예 : HL7 은 잘 정의 된 데이터 유형 사용 ). 그들 중 많은 사람들이 이처럼 자세하게 설명하지는 않습니다.

내부 기록에 대한 정부 주도 표준

국가 또는 지방 정부는 종종 공무원의 개인 정보를 기록하고 저장해야 할 필요성이 높으며, 다양한 수준의 성공과 파트너 조직과의 상호 운용성을 통해 조직 전체에서 구현하는 자체 "표준"을 분명히 제시했습니다. .

뉴질랜드 정부의 신원 기록 표준 데이터 형식 이 그 예 입니다.

소프트웨어의 공장 표준

이를 통해 영감을 얻거나 알려진 오픈 소스 CRM 소프트웨어 소스를 사용하여 고객 데이터의 데이터 사양에 대한 모범 사례 및 지침으로 사용할 수 있습니다.

참고 항목 10 가지 오픈 소스 비즈니스 및 소셜 CRM 소프트웨어 당신이 그들의 데이터 모델 자신을 볼 수있는 목록을.

EDI 시스템에 대한 표준을 찾아야한다고 말하고 싶습니다 . 수백 개의 '표준'문서가 있으므로 요구 사항에 따라 하나를 선택해야합니다. 예를 들어, 원하는 필드를 가져올 수있는 TRADACOMS 송장 형식 이 있습니다.

열기 응용 프로그램 그룹은 응용 프로그램 구현과 상호 운용성을위한 개방형 표준의 집합을 게시합니다. 이들은 주로 XML 지향적이지만 개별 필드와 크기를 가진 표준 고객 레코드를 지정합니다 ( CustomerPartyMaster문서 표준 목록 참조).

나는 "아직 필요하지 않을 것입니다"라고 말할 것입니다. 그리고 Ron Jeffries와 함께 : "실제로 필요할 때 항상 구현하십시오. 필요할 때만 예측할 수는 없습니다."

따라서 구체적인 데이터베이스를 프로젝트에 추가해야 할 경우에는 거기에 저장 될 데이터에 대해 훨씬 더 많은 지식을 가지고있을 것입니다.