Де-факто стандарты для записи информации о клиентах [закрыто]

В настоящее время я оцениваю потенциальный новый проект, который включает в себя создание БД для типичной информации о клиенте (ИД пользователя, имя пользователя, имя и фамилия, адрес электронной почты, адрес, telfnr ...). На данный момент требования определены только приблизительно.

Ожидается, что клиентская БД в O (миллионах) записей. Для того, чтобы вычислить некоторые числа «за пределами конверта» для определения размера БД и оценить возможные варианты и архитектуры БД, я ищу некоторые де-факто стандарты для таких записей. В частности, размер std каждого поля (имя, фамилия, адрес, ...) или типичное значение avg для простой записи о клиенте было бы отличной информацией .

С таким количеством веб-сайтов электронной коммерции должна быть какая-то типичная конфигурация, которую можно использовать повторно и избегать повторного изобретения колеса.

Есть идеи?

---- редактировать ----

Ответы, кажется, направляются к принятию стандартной записи о клиентах по сравнению с разработкой вашей собственной. Я хотел бы подчеркнуть, что основное внимание в этом вопросе уделяется поиску ссылки для определения размера поля для объекта заказчика и избеганию самостоятельного выяснения этого (я выделил эту часть в исходном тексте - теперь выделен жирным шрифтом -)

Хорошая вещь о стандартах в том, что у вас есть так много на выбор. - Эндрю Стюарт Таненбаум

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

Там нет королевской дороги к дизайну или информации, которую вы хотите. Потратьте время и силы, чтобы получить требования и получить конкретную оценку. В противном случае вы будете скорее неправы, чем верны. Единственный способ узнать то, что вам нужно знать, это задать вопросы и выяснить это самостоятельно.

Многие CRM-системы используют так называемый объектный шаблон Expando, ранее известный как динамический шаблон свойств . В основном это словарная конструкция пары ключ-значение. За исключением очень особых случаев, это считается дизайном Anti-Pattern и его следует избегать.

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

Конкретные решения для конкретных случаев всегда будут лучше дизайн.

В стеке DBA есть нить о лучших практиках для общих областей, в которой обсуждаются проблемы. Очень важно, что вы планируете делать с данными и насколько тщательно вы должны быть. Если вам действительно нужно поддерживать все действительные адреса электронной почты или все действительные имена, ваши столбцы должны быть намного больше, чем если бы вы просто хотели поддерживать то, что ваша организация и приложение считают разумным подмножеством действительных значений.

Как отметил Джаррод, если вы будете следовать общему стандарту, вы обязательно получите формат записи, который включает в себя множество вещей, которые вашей системе никогда не понадобятся. Поскольку вы уже знаете, что будет достаточно большое количество записей, вероятно, у вас возникнут ненужные проблемы с производительностью, поскольку вы поддерживаете данные, которые никогда не будут использоваться. И наоборот, вполне вероятно, что стандарт не будет включать поля, которые вам нужны, что будет болезненной проблемой для решения; либо вы нарушаете стандарт, добавляя эти поля, либо вам придется найти какой-то (возможно, неуклюжий) способ включения нестандартных полей в стандарт.

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

Существующие международные стандарты

Существует довольно много стандартов, но определенных для определенных областей, с различными требованиями для каждого из них в зависимости от их потребностей в сборе данных.

Например, но не ограничиваясь (и исходя из опыта обоих):

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

• более широкое поле электронных медицинских карт и их технических стандартов

• программное обеспечение, связанное с записями данных о вызовах операторов мобильной связи и данными об услугах (не совсем стандартно, но для обеспечения взаимодействия между сетями партнеров).

Некоторые из приведенных выше ссылок ссылаются на довольно подробные документы, перечисляя даже требования к работоспособности и форматированию полей (например, HL7 использует четко определенные типы данных ). Во многих из них не стоит вдаваться в подробности.

Государственные стандарты для внутренних записей

Правительства, национальные или местные, часто испытывают острую потребность в регистрации и хранении личной информации для государственных учреждений и, очевидно, придумали собственные «стандарты», которые они применяют в своих организациях (с разным уровнем успеха и взаимодействия с партнерскими организациями). ,

Примером может служить этот Форматы данных для Стандарта записей от правительства Новой Зеландии.

Фактические стандарты в программном обеспечении

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

Посмотрите список 10 лучших программ для бизнеса и социального CRM с открытым исходным кодом , для которого вы сами можете посмотреть их модели данных.

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

Группа открытых приложений публикует набор открытых стандартов для реализации и взаимодействия приложений. Они в основном ориентированы на XML, но в них указывается стандартная запись клиента с отдельными полями и размерами (см. CustomerPartyMasterСписок стандартов документов).

Я бы сказал: «Тебе это не понадобится (пока)». А с Роном Джеффрисом: «Всегда воплощайте вещи в жизнь, когда они вам действительно нужны, а не тогда, когда вы предвидите, что они вам нужны».

Поэтому, возможно, если пришло время добавить конкретную базу данных в проект, у вас будет гораздо больше знаний о данных, которые будут там храниться.