Standard di fatto per il registro delle informazioni sui clienti [chiuso]

Attualmente sto valutando un potenziale nuovo progetto che prevede la creazione di un DB per le informazioni tipiche del cliente (userid, pwd, nome e cognome, e-mail, indirizzo, telfnr ...). A questo punto, i requisiti sono definiti solo approssimativamente.

Il DB del cliente è previsto nella O (milioni) di record. Al fine di calcolare alcuni numeri pronti per il dimensionamento dei DB e valutare potenziali opzioni e architetture di DB, sto cercando alcuni standard di fatto per questo tipo di record. In particolare, la dimensione standard di ogni campo (nome, cognome, indirizzo, ...) o avg tipico per un semplice record cliente sarebbe un'ottima informazione .

Con così tanti siti web di e-commerce là fuori, ci dovrebbe essere una sorta di configurazione tipica che può essere riutilizzata ed evitare di reinventare la ruota.

Qualche idea?

---- modificare ----

Le risposte sembrano orientarsi verso l'adozione di un record cliente standard rispetto alla progettazione del proprio. Vorrei sottolineare che l'obiettivo di questa domanda è individuare un riferimento per il dimensionamento dei campi per un oggetto cliente ed evitare di capirlo da solo (ho sottolineato quella parte del testo originale - ora in grassetto -)

La cosa bella degli standard è che hai così tanti tra cui scegliere. - Andrew Stuart Tanenbaum

Cose come queste sono molto specifiche per un cliente e per l'industria, qualsiasi cosa generica includerà tutto e il lavello della cucina. Soprattutto i formati di tipo EDI, nella maggior parte dei casi sono stati definiti organicamente nell'arco di un decennio o più e includono tutto ciò che ogni azienda del comitato abbia mai desiderato. Dovevano essere generici del settore e diventarono estremamente specifici per il settore ed estremamente fragili.

Non esiste una strada reale per il design o le informazioni desiderate. Fare il tempo e lo sforzo per ottenere i requisiti e ottenere una stima concreta. Altrimenti avrai più torto che giusto. L'unico modo per sapere cosa devi sapere è porre le domande e capirlo tu stesso.

Molti sistemi CRM utilizzano quello che ora viene chiamato un modello di oggetti Expando, precedentemente noto come modello di proprietà dinamico . È fondamentalmente un costrutto di dizionario di coppia chiave-valore. Fatta eccezione per casi molto speciali, è considerato un Anti-Pattern di design e dovrebbe essere evitato.

Negli ultimi 20 anni ho progettato e realizzato almeno 8 soluzioni CRM personalizzate, ognuna con requisiti diversi e nessuno dei modelli di dati (logici o fisici) avrebbe funzionato su tutti i domini.

Soluzioni specifiche per casi specifici saranno sempre progetti migliori.

C'è una discussione nello stack DBA sulle migliori pratiche per i campi delle persone comuni che discute i problemi. È molto importante cosa stai pianificando di fare con i dati e quanto accurato devi essere. Se devi effettivamente supportare tutti gli indirizzi e-mail validi o tutti i nomi validi, le tue colonne dovranno essere molto più grandi di se desideri semplicemente supportare qualunque organizzazione e applicazione considerino un sottoinsieme ragionevole dei valori validi.

Come ha sottolineato Jarrod, se segui uno standard generico, finirai sicuramente con un formato record che include molte cose che il tuo sistema non avrà mai bisogno. Dato che sai già che ci sarà un numero abbastanza elevato di record, è probabile che tu abbia problemi di prestazioni non necessari perché stai supportando dati che non verranno mai utilizzati. Al contrario, è anche probabile che lo standard non includa i campi di cui hai bisogno, il che sarà un problema doloroso da risolvere; o rompi lo standard aggiungendo questi campi, o dovrai trovare un modo (probabilmente ingombrante) per includere i campi non standard all'interno dello standard.

Penso che il vero problema qui non sia trovare uno standard adatto a tutti (che sarà quasi sempre adatto a nessuno) ma che ti è stato assegnato il compito di stimare una soluzione dove i requisiti non lo sono specificato ancora. In questi casi, penso che l'unica cosa professionale da fare sia fare una stima minima basata sui requisiti che hai e quindi fare una stima massima basata su tutti i possibili requisiti indefiniti che ritieni possano sorgere. Abbastanza sicuro, la stima potrebbe diventare ridicolmente approssimativa, nel qual caso dovresti spiegare a chiunque ti abbia assegnato questo compito, che non è possibile fare una buona stima fino a quando i requisiti non sono più ben definiti.

Standard internazionali esistenti

Esistono alcuni standard, ma specifici per determinati campi, con requisiti diversi per ciascuno di essi a seconda delle esigenze di raccolta dei dati.

Ad esempio, ma non limitato a (e parlando per esperienza con entrambi):

• Software relativo ai dati dei pazienti e alle cartelle cliniche se si prevede di essere certificati per determinate specifiche.
  • Standard di dati uniformi per l'acquisizione di informazioni sulla cartella clinica del paziente presso il punto di cura (presenta un elenco di diversi standard per le cartelle cliniche)
• Eletronic Medical Records e relativi standard tecnici

• il più ampio campo di Electronic Health Records e dei loro standard tecnici

• software relativo ai record di dati di chiamata degli operatori mobili e ai record di dati di servizio (non esattamente come standard, ma per l'interoperabilità tra le reti dei partner).

Alcuni dei collegamenti sopra riportati a documenti abbastanza dettagliati, che elencano anche i requisiti per l'integrità e la formattazione dei campi (ad esempio, HL7 utilizza tipi di dati ben definiti ). In molti di essi non vanno in questi dettagli.

Standard governativi per i record interni

I governi, nazionali o locali, hanno spesso un forte bisogno di registrare e archiviare informazioni personali per gli uffici pubblici e ovviamente hanno elaborato i propri "standard", che implementano nelle loro organizzazioni (con diversi livelli di successo e interoperabilità con le organizzazioni partner) .

Un esempio potrebbe essere questo formato di dati per Identity Records Standard del governo della Nuova Zelanda.

Standard di fatto nel software

È possibile trarre ispirazione da questi o utilizzare la fonte del noto software CRM open source da utilizzare come best practice e linee guida per le specifiche dei dati dei dati dei clienti.

Consulta l' elenco dei 10 migliori software Open Source e CRM per i quali puoi cercare tu stesso i loro modelli di dati.

Direi che devi trovare standard per i sistemi EDI . Esistono centinaia di documenti "standard", quindi dovresti sceglierne uno in base alle tue esigenze. Ad esempio, ecco un formato per la fattura TRADACOMS da cui puoi prendere i campi che desideri.

L'aprire le applicazioni gruppo pubblica un insieme di standard aperti per l'implementazione delle applicazioni e l'interoperabilità. Sono per lo più orientati all'XML, ma specificano un record cliente standard con singoli campi e dimensioni (cercare CustomerPartyMasternell'elenco degli standard del documento).

Direi "Non ne avrai ancora bisogno (ancora)". E con Ron Jeffries: "Implementa sempre le cose quando ne hai davvero bisogno, mai quando prevedi che ne hai bisogno."

Quindi, forse, se è il momento di aggiungere un database concreto al progetto, si ha molta più conoscenza dei dati che verranno memorizzati lì.