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

17

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

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

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

Есть идеи?

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

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

maasg
источник
1
Я хотел бы видеть информацию об этом тоже. Я тоже никогда не находил ничего подобного. Что было бы интересно, если бы кто-то сделал тематическое исследование по этому вопросу, просмотрев некоторые проекты с открытым исходным кодом.
программист
2
Жаль, что вы получили отрицательные отзывы о том, что действительно хороший вопрос о «профессионализме» программного обеспечения, не изобретая свой собственный формат записи.
gbjbaanb
Чувак, я бы хотел, чтобы в этой области была какая-то последовательность. Я импортировал базы данных клиентов из большого числа систем, и они по всей карте.
TehShrike
Вы планируете хранить информацию о номере телефона, адресе и т. д. только для одной конкретной страны? Это может сделать разницу в размере, который вам нужен.
HLGEM

Ответы:

16

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

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

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

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

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

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


источник
Я бы хотел +2 за последнее предложение!
Макс. Вечера
Благодарю. Я согласен с большинством ваших замечаний и, конечно же, основываю проект на надлежащей фазе требований. Тем не менее, для расчетов типа «за окном» я, безусловно, оценил бы разумные значения по умолчанию, которые можно было бы взять из разумного «фактического» стандарта, поэтому не такой стандарт, как форматы EDI, а скорее то, что люди используют каким-то распространенным способом. Таким образом, я мог собрать свой объект клиента и получить фигуру парного шара на рекордном размере.
Maasg
Моя точка зрения пропущена, все, что используется широко, будет слишком широким и обобщенным, чтобы быть полезным. Это будет раздутым и чрезмерно сложным. Именно здесь SAP, PeopleSoft и Salesforce делают свои деньги. Их материал обобщен до такой степени, что вам приходится платить большим $$$ консультантам, чтобы они подгоняли его под нужды вашей компании. Обычно это стоит во много раз дороже, чем разработка и поддержка специального пользовательского решения. И они зарабатывают деньги на продолжении работы , с постоянными несовместимыми обновлениями и тому подобным.
4

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

Джастин Кейв
источник
Это самое близкое, что я пришел к ответу на мой вопрос. Эти руководящие принципы являются довольно хорошими, хотя и не полными или конкретными, но определенно в правильном духе.
Maasg
3

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

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

Кристиан Пальмсьерна
источник
1

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

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

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

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

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

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

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

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

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

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

haylem
источник
De-Facto Standards in Software-> очень заинтересованы в этом. Не могли бы вы добавить некоторые ссылки?
Maasg
Downvoters, пожалуйста, объясните (было 2 только сейчас).
Хайлем
0

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

gbjbaanb
источник
0

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

TMN
источник
0

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

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

Хабакук
источник