Стандарти фактичного запису інформації про клієнтів [закрито]

Зараз я оцінюю потенційний новий проект, який передбачає створення БД для типової інформації про клієнтів (userid, pwd, ім’я та прізвище, електронна адреса, адреса, telfnr ...). На даний момент вимоги лише визначені приблизно.

Очікується, що клієнтська БД буде мати O (мільйони) записів. Для того, щоб обчислити деякі резервні номери конвертів для розміру БД та оцінити потенційні параметри та архітектури БД, я шукаю деякі фактичні стандарти для таких типів записів. Зокрема, великий розмір std кожного поля (ім'я, прізвище, адреса, ...) або типовий середній рівень для простого запису клієнта буде чудовою інформацією .

З такою кількістю веб-сайтів електронної комерції там має бути якась типова конфігурація, яку можна повторно використовувати і уникати повторного винайдення колеса.

Будь-які ідеї?

---- редагувати ----

Відповіді, здається, спрямовують на прийняття стандартних записів клієнтів проти створення власних. Я хотів би підкреслити, що в цьому питанні основна увага приділяється пошуку посилання на розмір поля для об’єкта клієнта, а також уникнути цього самостійно з'ясовувати. (Я наголошував на тій частині оригінального тексту - тепер жирним шрифтом -)

Приємна річ у стандартах - це те, що у вас є стільки, що можна вибрати. - Ендрю Стюарт Таненбаум

Такі речі дуже специфічні для замовника та галузі, а все загальне буде включати все та кухонну мийку. Особливо формати типу EDI, вони в більшості випадків були органічно визначені протягом десяти років і більше і включають все, що хотіла будь-яка компанія в комітеті. Вони повинні були бути галузевими, і вони стали надзвичайно специфічними для галузі та надзвичайно крихкими.

Королівської дороги до потрібного дизайну чи інформації немає. Вкладіть час і зусилля, щоб отримати вимоги та отримати конкретну оцінку. Інакше ви будете більше помилятися, ніж правильно. Єдиний спосіб дізнатися, що вам потрібно знати, - це задати питання і розібратися в цьому самостійно.

Багато систем CRM використовують те, що зараз називається об'єктним шаблоном Expando, раніше відомим як динамічний шаблон властивості . Це в основному конструкція словника пари ключових значень. За винятком дуже особливих випадків, це вважається дизайном Anti-Pattern і його слід уникати.

За останні 20 років я розробив і створив щонайменше 8 індивідуальних рішень для управління CRM, кожен і кожен мав різні вимоги, і жодна з моделей даних (логічна чи фізична) не працювала б для всіх областей.

Конкретні рішення для конкретних випадків завжди будуть кращими конструкціями.

У степі DBA є нитка про кращі практики для загальних сфер людини, яка обговорює проблеми. Дуже важливо, що ви плануєте робити з даними та наскільки ретельними ви повинні бути. Якщо вам потрібно підтримувати всі дійсні адреси електронної пошти або всі дійсні імена, ваші стовпці повинні бути набагато більшими, ніж якщо ви просто хочете підтримати те, що ваша організація та програма вважають розумним набором дійсних значень.

Як зауважив Джаррод, якщо ви будете дотримуватися загального стандарту, ви обов'язково отримаєте формат запису, який включає багато речей, які ваша система ніколи не потребуватиме. Оскільки ви вже знаєте, що буде досить велика кількість записів, швидше за все, у вас виникнуть непотрібні проблеми з продуктивністю, оскільки ви підтримуєте дані, які ніколи не будуть використовуватися. І навпаки, також є ймовірність, що стандарт не буде включати поля, які вам потрібні, що буде болісною проблемою; або ви порушите стандарт, додавши ці поля, або вам доведеться знайти якийсь (ймовірно незграбний) спосіб включення нестандартних полів до стандарту.

Я думаю, що справжня проблема тут не в тому, щоб знайти стандарт одного розміру (який майже завжди буде один-розмір-НІКОЛИ), а в тому, що вам поставили завдання оцінити рішення, коли вимоги не відповідають уточнено ще. У цих випадках я думаю, що єдине професійне, що потрібно зробити, - це скласти мінімальну оцінку, виходячи з ваших вимог, а потім зробити максимальну оцінку на основі всіх можливих невизначених вимог, які, на вашу думку, можуть виникнути. Звичайно, оцінка може стати смішно грубою, і в цьому випадку ви повинні пояснити тому, хто вам це доручив, що робити хорошу оцінку просто неможливо, поки вимоги не будуть більш чітко визначені.

Існуючі міжнародні стандарти

Існує досить багато стандартів, але специфічних для певних галузей, з різними вимогами до кожного з них залежно від потреб у зборі даних.

Наприклад, але не обмежуючись ними (і спілкуючись із досвідом роботи з обома цими):

• Програмне забезпечення, що стосується даних про пацієнтів та медичних записів, якщо ви плануєте сертифікацію на певні характеристики.
  • Єдині стандарти даних щодо взяття інформації про медичну документацію пацієнтів у пункті обслуговування (представлений перелік різних стандартів медичної документації)
• Медичні записи Eletronic та їх технічні стандарти

• більш широке поле Електронних медичних записів та їх Технічні стандарти

• програмне забезпечення, що стосується записів даних про дзвінки мобільних операторів та записів даних про послуги (не зовсім як стандарт, але для взаємодії між партнерськими мережами).

Деякі з наведених вище посилань на досить детальні документи, перелічуючи навіть вимоги щодо здоров'я та форматування полів (наприклад, HL7 використовує чітко визначені типи даних ). Однак, багато з них не дуже детально описуються.

Нормативи внутрішніх записів, керовані урядом

Уряди, національні чи місцеві, часто мають гостру потребу записувати та зберігати особисту інформацію для державних служб, і, очевидно, придумали власні "стандарти", які вони застосовують у своїх організаціях (з різним рівнем успішності та взаємодії з організаціями-партнерами) .

Прикладом можуть бути такі формати даних для стандарту записів про особу від уряду Нової Зеландії.

Стандарти дефакто в програмному забезпеченні

Ви можете взяти натхнення з них або використати джерело відомого програмного забезпечення з відкритим кодом для управління CRM, щоб використовувати як найкращі практики та рекомендації для специфікацій даних ваших клієнтських даних.

Перегляньте список найкращих 10 програм з відкритим кодом для бізнес-та соціальних програм CRM , для яких ви самі можете знайти їх моделі даних.

Я б сказав, що вам потрібно знайти стандарти для систем EDI . Є сотні «стандартних» документів, тому вам потрібно вибрати один, виходячи зі своїх вимог. Наприклад, ось формат для рахунку-фактури TRADACOMS, з якого ви можете захопити потрібні поля.

Група " Відкриті додатки" публікує набір відкритих стандартів для впровадження додатків та сумісності. Вони в основному орієнтовані на XML, але вони вказують стандартний запис клієнта з окремими полями та розмірами (шукайте CustomerPartyMasterу списку стандартів документів).

Я б сказав: "Вам це ще не знадобиться". І з Ронам Джефрісом: "Завжди реалізовуйте речі, коли вони вам справді потрібні, ніколи, коли ви просто передбачите, що вони вам потрібні".

Тож, можливо, якщо пора додати конкретну базу даних до проекту, ви маєте набагато більше знань про дані, які там будуть зберігатися.