Объясняя, почему "просто добавить еще один столбец в БД" - это плохая идея для программистов [закрыто]

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

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

продавцы не ориентированы на продажи. Вот что их их совершение. Им все равно, что будет потом. Боссы, однако, сосредоточены на стоимости. Продавайте своим боссам, а ваши боссы могут продавать продавцам.

Ах.. немного знаний-опасная вещь.

попробуйте вот это:

вы: какие компании мы не смогли продать?
продажи: Acme Industries, OCP Corp, бла-бла-бла
вы: хорошо.... почему бы тебе не сделать еще пару телефонных звонков?

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

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

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

• Это займет больше времени для них, чтобы получить свои данные - они действительно хотят ждать и ждать?

• Это будет сложнее и займет больше времени для разработки запросов для создания отчетов - опять же, если им нужен этот запрос завтра, они хотят, чтобы им сказали, что он все еще работает?

• Это будет кошмар для поддержания, с ошибкой склонные запросы, скорее всего, будут написаны.

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

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

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

Google "технический долг"; показать им результаты.

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

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

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

проблема в том, что "мы пытаемся сохранить базу данных хорошо нормализованной" почти наверняка неправильно ответ-он воспроизводит мяч в суд недоверия и перекрестных целей.

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

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

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

Если требования слишком дороги, чтобы когда-либо реализовать, то это часть бизнес-кейс. Вы недостаточно рассказали нам об архитектуре или типе объектов, которые моделируют эти таблицы. Допустим, у вас 100 клиентов. В определенном объекте может быть перекрытие столбцов. Так же, как 95% клиентов никогда не будут использовать дополнительный платежный адрес или столбец среднего имени, это не означает, что они колонны не учитываются-мало того, они часто находятся в оригинальном дизайне! Кроме того, если это таблица Products, и каждый клиент хочет много специальных столбцов и нет перекрытия, вам может понадобиться пользовательская система полей (EAV/XML/tag-дизайн должен будет соответствовать требованиям) вместо того, чтобы поддерживать согласованный дизайн системы.

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

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

дайте им понять, сколько это стоит во время разработки, это изменение потребует 1 или два времени разработчиков? а как насчет тестирования? если сложные запросы стоят дороже, то компания в целом делает меньше на работе. Менеджер учетной записи / проекта должен быть посредником, который должен буферизировать эти типы запросов.

вы ничего не получите, объясняя это им в технических терминах. Тебе нужна метафора. Адаптируйте его к человеку, с которым вы разговариваете, если можете. Если он / она-урод автомобиля, заставьте их думать с точки зрения модификаций двигателя. Сколько будет стоить Ford, чтобы предложить три разных двигателя в Taurus или пользовательские моды по требованию?

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

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

чтобы расширить предложение tuinstoel (избегайте общих структур entity-attribute-value): хотя мне обычно нравится эта структура для легкого использования, чрезмерное (что бы это ни значило) использование ухудшит производительность, как отмечалось. Такие структуры не могут быть проиндексирован. Я написал и поддержал одну такую систему. К тому времени, когда у нас было 50 000 "сущностей" каждый с 10-100 ключами, он был медленным даже на аппаратном обеспечении среднего уровня).

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

другим возможным вариантом может быть добавление ряда неиспользуемых общих столбцов в соответствующие таблицы, которые будут использоваться клиентами для своих собственных целей. Некоторые приложения для предприятий делают именно это. Таблица продаж может иметь десять или двадцать столбцов CUSTCODE01-CUSTCODE10, которые каждое развертывание приложения может использовать по-разному, полностью настраиваемым способом.

этот может на первый взгляд выглядеть ужасно, это также может быть счастливой средой. Существует достаточное количество возможностей для настройки на основе каждого клиента без а)" просто добавления столбца " и нарушения процесса приложения или разработки или б) реализации потенциально медленной общей системы. Однако вы получаете только ограниченное количество felxablity, и нет самодокументированных имен столбцов (но описания столбцов могут быть настроены по мере необходимости).

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

Похоже, вы хотите построить какую-то общую модель данных? Сущность-атрибут-значение...?

эти общие модели часто очень медленно, они не могут быть проиндексированы должным образом и запутать оптимизатор запросов. Часто лучше просто добавить несколько столбцов.

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

возможно, это зависит от поставщика БД, но если вы используете Oracle, я бы предпочел "просто добавить несколько столбцов" над entity-attribute-value-road.

вы можете объяснить эту проблему, проводя сравнение с библиотекой. Есть много книг. Маленькие и большие, тонкие и толстые - это каждый может себе представить. Теперь, если вы хотите хранить больше информации где - то, было бы гораздо проще добавить несколько новых страниц в книгу, чем увеличить некоторые отдельные страницы-если есть несколько страниц книги больше, чем другие, это не очень надежно, и как можно найти эту информацию, если она не имеет записи в индексе содержания? Может быть, это лучше хранить новую дополнительную информацию в следующей книге, новой с определенной структурой. Представьте себе, как можно получить информацию, если все содержание библиотеки будет записано в одной большой толстой книге? Никто другой не мог ничего найти, пока вы не найдете то, что хотите, и не поставите книгу на место...если вы в состоянии нести эту огромную книгу. Зачем восстанавливать всю живую историю, если вы только хотите знать дату рождения человека?

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