Faktyczne standardy zapisu informacji o kliencie [zamknięte]

17

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 )

Maasg
źródło
1
Chciałbym też zobaczyć informacje na ten temat. Nigdy też nie znalazłem czegoś takiego. Interesujące byłoby, gdyby ktoś zrobił studium przypadku na ten temat, oglądając niektóre projekty open source.
programista
2
szkoda, że ​​nie doceniasz tego, co jest naprawdę dobrym pytaniem na temat „profesjonalizmu” oprogramowania, nie odkrywając na nowo własnego formatu nagrań.
gbjbaanb
Człowieku, chciałbym, żeby w tym obszarze była jakaś konsekwencja. Zaimportowałem bazy danych klientów z wielu systemów i są one na całej mapie.
TehShrike
czy planujesz przechowywać informacje o numerze telefonu, adresie itp. tylko dla jednego określonego kraju? Może to powodować różnice w rozmiarze, którego potrzebujesz.
HLGEM,
1
Być może zechcesz sprawdzić stronę domową Stowarzyszenia Standardów Technologii Detalicznych
Użytkownik

Odpowiedzi:

16

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.


źródło
Chciałbym móc +2 za ostatnie zdanie!
Maxpm
Dzięki. Zgadzam się z większością twoich uwag i na pewno oparłbym projekt na właściwej fazie wymagań. To powiedziawszy, w przypadku obliczeń na zapleczu z pewnością doceniłbym rozsądne wartości domyślne, które można by wziąć z rozsądnego standardu „de facto”, a więc nie standardu takiego jak formaty EDI, ale raczej coś, czego ludzie używają w jakiś powszechny sposób. W ten sposób mogłem zmontować obiekt klienta i uzyskać figurkę ball-park o rekordowej wielkości.
maasg
Chodzi mi o to, że wszystko, co jest powszechnie stosowane, będzie o wiele za szerokie i uogólnione, aby było przydatne. Będzie wzdęty i nadmiernie skomplikowany. To tutaj zarabiają SAP, PeopleSoft i Salesforce. Ich rzeczy są uogólnione do tego stopnia, że ​​trzeba zapłacić wysokich konsultantów $$$, aby dostosować je do potrzeb Twojej firmy. Zwykle kosztuje to wiele razy tyle, ile kosztowałoby opracowanie i utrzymanie niestandardowego rozwiązania. I zarabiają pieniądze na pracy po pracy , przy ciągłych niezgodnych aktualizacjach i tym podobnych.
4

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.

Justin Cave
źródło
To jest najbliższa odpowiedź na moje pytanie. Wytyczne te są dość dobre, choć nie kompletne ani konkretne, ale zdecydowanie we właściwym duchu.
maasg
3

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.

Christian Palmstierna
źródło
1

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):

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.

Haylem
źródło
De-Facto Standards in Software-> bardzo się nimi interesuję. Czy możesz dodać jakieś referencje?
maasg
Downvoters, proszę wyjaśnij (w tej chwili było ich 2).
haylem
0

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.

gbjbaanb
źródło
0

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).

TMN
źródło
0

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.

habakuk
źródło