Faktyczne standardy zapisu informacji o kliencie [zamknięte]

Obecnie oceniam potencjalny nowy projekt, który obejmuje utworzenie bazy danych dla typowych informacji o kliencie (identyfikator użytkownika, pwd, imię i nazwisko, adres e-mail, adres, telfnr ...). W tym momencie wymagania są jedynie z grubsza zdefiniowane.

DB klienta jest oczekiwany w O (milionach) rekordów. Aby obliczyć niektóre liczby z tyłu koperty dla rozmiaru DB i ocenić potencjalne opcje i architektury DB, szukam pewnych faktycznych standardów dla tego rodzaju rekordów. W szczególności świetny byłby standardowy rozmiar każdego pola (imię, nazwisko, adres, ...) lub typowa średnia dla zwykłego rekordu klienta .

Przy tak wielu witrynach e-commerce powinna istnieć jakaś typowa konfiguracja, której można użyć ponownie i uniknąć ponownego wynalezienia koła.

Jakieś pomysły?

---- edytować ----

Wydaje się, że odpowiedzi zmierzają w kierunku przyjęcia standardowego rekordu klienta, a nie zaprojektowania własnego. Chciałbym podkreślić, że celem tego pytania jest zlokalizowanie odniesienia do zmiany rozmiaru pola dla obiektu klienta i unikanie samodzielnego rozgryzania tego (podkreśliłem tę część w oryginalnym tekście - teraz pogrubionym drukiem )

Zaletą standardów jest to, że masz tak wiele do wyboru. - Andrew Stuart Tanenbaum

Takie rzeczy są bardzo specyficzne dla klienta i branży, wszystko, co ogólne, obejmuje wszystko i zlew kuchenny. Zwłaszcza formaty typu EDI, w większości przypadków były definiowane organicznie przez ponad dekadę lub dłużej i obejmują wszystko, czego każda firma w komitecie kiedykolwiek chciała. Miały być rodzajowe dla branży i stały się wyjątkowo specyficzne dla branży i wyjątkowo kruche.

Nie ma królewskiej drogi do projektu lub informacji, których potrzebujesz. Wykonaj czas i wysiłek, aby uzyskać wymagania i uzyskać konkretną wycenę. W przeciwnym razie będziesz bardziej się mylił niż poprawiał. Jedynym sposobem, aby wiedzieć, co musisz wiedzieć, jest zadawanie pytań i samodzielne rozwiązywanie tego.

Wiele systemów CRM korzysta z tak zwanego wzorca obiektów Expando, znanego wcześniej jako wzorzec właściwości dynamicznych . Jest to w zasadzie konstrukcja słownika pary klucz-wartość. Z wyjątkiem bardzo szczególnych przypadków jest uważany za anty-wzór projektowy i należy go unikać.

Mam zaprojektowany i zbudowany co najmniej 8 niestandardowych rozwiązań CRM w ciągu ostatnich 20 lat, każdy i każdy ma inne wymagania i żaden z modeli danych (logicznych lub fizycznych) będzie pracował w różnych dziedzinach dla wszystkich domen.

Konkretnymi rozwiązaniami dla konkretnych przypadków zawsze będą lepsze projekty.

W stosie DBA znajduje się wątek najlepszych praktyk dla pól zwykłych osób, który omawia problemy. Bardzo ważne jest, co planujesz zrobić z danymi i jak dokładny musisz być. Jeśli rzeczywiście potrzebujesz obsługiwać wszystkie prawidłowe adresy e-mail lub wszystkie prawidłowe nazwy, Twoje kolumny będą musiały być znacznie większe niż gdybyś tylko chciał obsługiwać to, co Twoja organizacja i aplikacja uważają za rozsądny podzbiór prawidłowych wartości.

Jak zauważył Jarrod, jeśli zastosujesz się do standardowego standardu, na pewno skończysz z formatem rekordu, który zawiera wiele rzeczy, których twój system nigdy nie będzie potrzebował. Ponieważ już wiesz, że będzie dość duża liczba rekordów, prawdopodobnie wystąpią niepotrzebne problemy z wydajnością, ponieważ obsługujesz dane, które nigdy nie zostaną wykorzystane. I odwrotnie, jest również prawdopodobne, że standard nie będzie zawierał potrzebnych pól, co będzie bolesnym problemem do rozwiązania; albo złamiesz standard, dodając te pola, albo będziesz musiał znaleźć jakiś (prawdopodobnie niezdarny) sposób na włączenie niestandardowych pól do standardu.

Myślę, że prawdziwym problemem tutaj nie jest znalezienie uniwersalnego standardu (który prawie zawsze będzie uniwersalny - BRAK), ale zadanie oszacowania rozwiązania, w którym wymagania nie są spełnione określone jeszcze. W takich przypadkach uważam, że jedyną profesjonalną rzeczą do zrobienia jest dokonanie minimalnego oszacowania na podstawie posiadanych wymagań, a następnie dokonanie maksymalnego oszacowania na podstawie wszystkich możliwych nieokreślonych wymagań, które według ciebie mogą się pojawić. Rzeczywiście, oszacowanie może stać się absurdalnie szorstkie, w takim przypadku powinieneś wyjaśnić temu, kto ci to zlecił, że po prostu nie jest możliwe dokonanie dobrego oszacowania, dopóki wymagania nie zostaną lepiej określone.

Istniejące standardy międzynarodowe

Istnieje wiele standardów, ale specyficznych dla niektórych dziedzin, z różnymi wymaganiami dla każdego z nich, w zależności od potrzeb w zakresie gromadzenia danych.

Na przykład, ale nie wyłącznie (i rozmawiając z doświadczenia z obydwoma):

• Oprogramowanie do obsługi danych pacjentów i dokumentacji medycznej, jeśli planujesz uzyskać certyfikat na określone specyfikacje.
  • Jednolite standardy danych dotyczące przechwytywania informacji o dokumentacji medycznej pacjenta w punkcie opieki (przedstawia listę różnych standardów dokumentacji medycznej)
• Eletronic Medical Records i ich standardy techniczne

• szerszy zakres elektronicznej dokumentacji medycznej i ich standardów technicznych

• oprogramowanie obsługujące rekordy danych połączeń operatorów telefonicznych i rekordy danych usług (nie dokładnie w standardzie, ale dla interoperacyjności między sieciami partnerskimi).

Niektóre z powyższych linków prowadzą do dość szczegółowych dokumentów, wymieniając nawet wymagania dotyczące kondycji i formatowania pól (na przykład HL7 wykorzystuje dobrze zdefiniowane typy danych ). W wielu z nich jednak nie są tak szczegółowe.

Standardy rządowe dotyczące rejestrów wewnętrznych

Rządy, krajowe lub lokalne, często mają silną potrzebę rejestrowania i przechowywania danych osobowych dla urzędów publicznych i oczywiście opracowały własne „standardy”, które wdrażają we wszystkich swoich organizacjach (z różnym poziomem sukcesu i interoperacyjności z organizacjami partnerskimi) .

Przykładem mogą być te formaty danych dla standardu rekordów tożsamości wydane przez rząd Nowej Zelandii.

Standardy de-Facto w oprogramowaniu

Możesz czerpać z nich inspirację lub skorzystać ze źródła znanego oprogramowania CRM typu open source, aby wykorzystać najlepsze praktyki i wytyczne dotyczące specyfikacji danych danych klientów.

Zobacz listę 10 najlepszych oprogramowania CRM dla przedsiębiorstw i społeczności o otwartym kodzie źródłowym , dla której możesz samodzielnie sprawdzić ich modele danych.

Powiedziałbym, że musisz znaleźć standardy dla systemów EDI . Istnieją setki „standardowych” dokumentów, więc musisz wybrać jeden na podstawie swoich wymagań. Na przykład, oto format faktury TRADACOMS , z której można pobierać pola, które chcesz.

Grupa Open Applications publikuje zestaw otwartych standardów wdrażania aplikacji i interoperacyjności. Są one głównie zorientowane na XML, ale określają standardowy rekord klienta z indywidualnymi polami i rozmiarami (poszukaj na CustomerPartyMasterliście standardów dokumentów).

Powiedziałbym: „Nie będziesz tego (jeszcze) potrzebował”. I z Ronem Jeffriesem: „Zawsze wdrażaj rzeczy, kiedy ich naprawdę potrzebujesz, nigdy, gdy tylko przewidujesz, że ich potrzebujesz”.

Może więc, jeśli czas dodać konkretną bazę danych do projektu, masz znacznie więcej wiedzy na temat danych, które będą tam przechowywane.