Каковы аргументы против объединения контактных данных в одно поле?

Question

У нас есть клиент, который настаивает на том, чтобы контактные данные, в настоящее время имена и фамилии, были в одном поле.Взять, к примеру, мистера Боба Смита и миссис Джейн Смит.Мистер Боб и миссис Джейн будут введены в поле имени, а Смит - в фамилию.Это усложняется, если контакты имеют разные фамилии или если есть дефис.Клиенту нужна только одна запись о контакте, поэтому он придумал эту систему и внедрил ее самостоятельно.

Наша система разработана на основе контактов, и каждый отдельный человек предназначен для индивидуального контакта, даже в браке.Из-за некоторых атрибутов, которые мы должны присваивать людям и заметкам, которые мы должны хранить, контакт-ориентированный подход является лучшим.Вышеуказанная проблема возникает примерно в 1/3 случаев, которые мы обрабатываем.

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

Есть предложения о том, как мы продаем это клиенту?

Answer 1

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

Им, возможно, придется усвоить этот урок трудным путем для себя. Я вижу больше проблем с переключением имен, например, ввод Смита в качестве имени и Боба в качестве последнего.

Кроме того, вы можете сделать оба поля обязательными для заполнения?

---

Похоже, то, что они хотят ввести, похоже на AddressLine1, AddressLine2. Это просто плохой дизайн, я думал, что у вас есть 2 поля имени, но они будут вводить данные только в одно из них (имя).

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

Answer 2

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

Если они захотят сделать одну рассылку для каждого "домашнего хозяйства", тогдаЯ уверен, что ваше приложение может сделать это.(Вероятно, это уже так.) Вы просто должны договориться о том, что означает «домашнее хозяйство».Так как могут быть арендованы комнаты или гости, находящиеся на длительный срок, это не всегда означает «только одну рассылку на адрес».

FWIW, я занимался этим десятилетиями и до сих пор нахожу врачейи адвокаты (и их сотрудники), с которыми труднее всего иметь дело.Однажды я вышел из собрания (и, конечно, потерял шанс подать заявку на контракт), когда айтишник доктора встал, ударил кулаком по столу и кричал на меня снова и снова: «Врачи не человек! Врачи не человек! ".

Answer 3

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

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

Answer 4

Разве вы не можете просто создать представление, которое содержит имя и фамилию вместе?Для некоторых серверов вы также можете создавать редактируемые представления ... Таким образом, ваш клиент будет счастлив, и данные будут храниться в нормализованном виде.

Answer 5

Просто покажите вашему клиенту нормальные формы для проектирования базы данных:
> http://www.phlonx.com/resources/nf3/

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