De-facto-Standards für Kundeninformationsdatensätze [geschlossen]

Derzeit prüfe ich ein potenzielles neues Projekt, bei dem eine Datenbank für typische Kundeninformationen (Benutzer-ID, Kennwort, Vor- und Nachname, E-Mail-Adresse, Adresse, Telefonnummer ...) erstellt wird. Die Anforderungen sind an dieser Stelle nur grob definiert.

Der Kunden-DB wird in O (Millionen) von Datensätzen erwartet. Um einige Back-of-the-Envelope-Zahlen für die DB-Dimensionierung zu berechnen und mögliche DB-Optionen und -Architekturen zu bewerten, suche ich nach De-facto-Standards für diese Art von Datensätzen. Insbesondere die Standardgröße jedes Feldes (Vorname, Nachname, Adresse, ...) oder der typische Durchschnitt für einen einfachen Kundendatensatz wäre eine großartige Information .

Bei so vielen E-Commerce-Websites sollte es eine Art typische Konfiguration geben, die wiederverwendet werden kann, und es sollte vermieden werden, das Rad neu zu erfinden.

Irgendwelche Ideen?

---- bearbeiten ----

Die Antworten scheinen darauf zu lenken, einen Standard-Kundenrekord zu übernehmen, statt einen eigenen zu entwerfen. Ich möchte betonen, dass der Schwerpunkt dieser Frage darin besteht, eine Referenz für die Feldgröße für ein Kundenobjekt zu finden und dies nicht selbst herauszufinden (ich habe diesen Teil im Originaltext hervorgehoben - jetzt fett gedruckt -).

Das Schöne an Standards ist, dass Sie so viele zur Auswahl haben. - Andrew Stuart Tanenbaum

Solche Dinge sind sehr spezifisch für einen Kunden und die Branche, alles, was generisch ist, umfasst alles und das Spülbecken. Insbesondere EDI-Formate wurden in den meisten Fällen über ein Jahrzehnt oder länger organisch definiert und umfassen alles, was jedes Unternehmen im Ausschuss jemals wollte. Sie sollten branchenüblich sein und wurden extrem branchenspezifisch und extrem spröde.

Es gibt keine königliche Straße zum Entwurf oder zu den Informationen, die Sie wünschen. Nehmen Sie sich Zeit und Mühe, um die Anforderungen zu ermitteln und einen konkreten Kostenvoranschlag zu erhalten. Sonst liegst du mehr falsch als richtig. Die einzige Möglichkeit zu wissen, was Sie wissen müssen, besteht darin, die Fragen zu stellen und selbst herauszufinden.

Viele CRM-Systeme verwenden ein sogenanntes Expando-Objektmuster, das früher als dynamisches Eigenschaftsmuster bezeichnet wurde . Es ist im Grunde ein Schlüsselwertpaar-Wörterbuchkonstrukt. Mit Ausnahme sehr spezieller Fälle gilt es als Design-Anti-Pattern und sollte vermieden werden.

Ich habe in den letzten 20 Jahren mindestens 8 kundenspezifische CRM-Lösungen entworfen und gebaut, wobei jede und jeder unterschiedliche Anforderungen hatte und keines der Datenmodelle (logisch oder physisch) für alle Domänen auf der ganzen Linie funktioniert hätte.

Spezifische Lösungen für bestimmte Fälle werden immer bessere Designs sein.

Der DBA-Stapel enthält einen Thread mit Best Practices für allgemeine Personenfelder , in dem die Probleme erläutert werden. Es ist sehr wichtig, was Sie mit den Daten vorhaben und wie gründlich Sie sein müssen. Wenn Sie tatsächlich alle gültigen E-Mail-Adressen oder alle gültigen Namen unterstützen müssen, müssen Ihre Spalten viel größer sein, als wenn Sie lediglich unterstützen möchten, unabhängig davon, welche Organisation und Anwendung eine angemessene Teilmenge der gültigen Werte betrachtet.

Wie Jarrod hervorhob, werden Sie definitiv ein Aufnahmeformat haben, das viele Dinge enthält, die Ihr System niemals benötigen wird, wenn Sie einem allgemeinen Standard folgen. Da Sie bereits wissen, dass es eine relativ große Anzahl von Datensätzen geben wird, treten möglicherweise unnötige Leistungsprobleme auf, da Sie Daten unterstützen, die niemals verwendet werden. Umgekehrt ist es auch wahrscheinlich, dass der Standard keine Felder enthält, die Sie benötigen. Dies ist ein schmerzhaftes Problem. Entweder Sie brechen den Standard, indem Sie diese Felder hinzufügen, oder Sie müssen einen (wahrscheinlich klobigen) Weg finden, die nicht standardmäßigen Felder in den Standard einzubeziehen.

Ich denke, das eigentliche Problem besteht hier nicht darin, einen Standard zu finden, der für alle geeignet ist (der fast immer für alle geeignet ist), sondern dass Sie beauftragt wurden, eine Lösung zu finden, bei der die Anforderungen nicht zutreffen noch nicht festgelegt. In diesen Fällen ist es meines Erachtens die einzige professionelle Aufgabe, eine minimale Schätzung basierend auf den Anforderungen vorzunehmen, die Sie haben, und dann eine maximale Schätzung basierend auf allen möglichen undefinierten Anforderungen, von denen Sie glauben, dass sie auftreten könnten. Sicherlich kann die Schätzung lächerlich grob werden. In diesem Fall sollten Sie demjenigen, der Sie damit beauftragt hat, erklären, dass es einfach nicht machbar ist, eine gute Schätzung vorzunehmen, bis die Anforderungen klarer definiert sind.

Bestehende internationale Standards

Es gibt eine ganze Reihe von Standards, die jedoch für bestimmte Bereiche spezifisch sind und für die je nach Bedarf an Datenerfassung unterschiedliche Anforderungen gelten.

Zum Beispiel, aber nicht beschränkt auf (und aus Erfahrung mit diesen beiden):

• Software für den Umgang mit Patientendaten und medizinischen Aufzeichnungen, wenn Sie vorhaben, für bestimmte Spezifikationen zertifiziert zu werden.
  • Einheitliche Datenstandards für die Erfassung von Patientenakteninformationen am Point of Care (enthält eine Liste verschiedener Standards für Patientenakten)
• Eletronic Medical Records und ihre technischen Standards

• das breitere Feld der elektronischen Patientenakten und ihre technischen Standards

• Software für Anruf- und Servicedatensätze von Mobilfunkanbietern (nicht standardmäßig, aber für die Interoperabilität zwischen Partnernetzen).

Einige der oben genannten Links führen zu ziemlich detaillierten Dokumenten, in denen sogar die Anforderungen an den Zustand und die Formatierung von Feldern aufgeführt sind ( HL7 verwendet beispielsweise genau definierte Datentypen ). Viele von ihnen gehen jedoch nicht so detailliert vor.

Von der Regierung vorgegebene Standards für interne Aufzeichnungen

Nationale oder lokale Regierungen haben häufig ein starkes Bedürfnis, persönliche Informationen für öffentliche Ämter zu erfassen und zu speichern, und haben offensichtlich eigene "Standards" entwickelt, die sie in ihren Organisationen umsetzen (mit unterschiedlichem Erfolg und Interoperabilität mit Partnerorganisationen). .

Ein Beispiel könnten diese Datenformate für den Identitätsdatensatzstandard der neuseeländischen Regierung sein.

De-Facto-Standards in der Software

Sie können sich von diesen inspirieren lassen oder die Quelle bekannter Open-Source-CRM-Software als Best Practices und Richtlinien für die Datenspezifikationen Ihrer Kundendaten verwenden.

In der Liste der Top 10 Open-Source-CRM-Software für Unternehmen und soziale Netzwerke können Sie die Datenmodelle selbst nachschlagen.

Ich würde sagen, Sie müssen Standards für EDI-Systeme finden . Es gibt Hunderte von "Standard" -Dokumenten, daher müssen Sie eines entsprechend Ihren Anforderungen auswählen. Hier ist beispielsweise ein Format für die TRADACOMS-Rechnung , aus dem Sie die gewünschten Felder abrufen können .

Die Open Applications Group veröffentlicht eine Reihe offener Standards für die Implementierung und Interoperabilität von Anwendungen. Sie sind größtenteils XML-orientiert, geben jedoch einen Standard-Kundendatensatz mit individuellen Feldern und Größen an (siehe CustomerPartyMasterListe der Dokumentstandards).

Ich würde sagen "Du wirst es (noch) nicht brauchen". Und mit Ron Jeffries: "Implementiere Dinge immer dann, wenn du sie wirklich brauchst, niemals, wenn du nur voraussiehst, dass du sie brauchst."

Wenn es also an der Zeit ist, dem Projekt eine konkrete Datenbank hinzuzufügen, wissen Sie viel mehr über die Daten, die dort gespeichert werden.