При объяснении, почему “Просто добавляют, другой столбец к DB” является плохой идеей, к не [закрытые] программисты

Вы можете объяснить эту проблему, сравнив ее с библиотекой. Книг много. Маленький и большой, тонкий и толстый - это может представить каждый. Теперь, если вы хотите где-то хранить больше информации, было бы проще добавить несколько новых страниц в книгу, чем увеличивать отдельные страницы - если в книге несколько страниц больше, чем другие, это не очень надежно, и как можно найти эта информация, если она не имеет записи в указателе содержания? Может быть, лучше сохранить новую дополнительную информацию в другой книге, в новой с определенной структурой. Imagine how one may get a information if the whole contens of a library would be written in one big thick book? Nobody else could find anything until you find what you want and set the book back at its place...if you are able to carry this enormous book. Why retrieving the whole Livestory if you only want to know the birthdate of a person?

The mentioned people don't have to understand the architecture of a database but they should trust you. And you organize it so that they can throw their information in this big hole of database and get it back when ever they want it - fast and reliable.

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

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

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

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

Возможно, это зависит от поставщика базы данных, но если вы используете Oracle, я бы предпочел дорогу «просто добавить несколько столбцов» над дорогой сущность-атрибут-значение.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Чтобы расширить предложение Tuinstoel (избегайте общих структур сущность-атрибут-значение): Хотя в целом мне нравится эта структура для легкого использования, чрезмерное (что бы это ни значило) использование ухудшило производительность, как отмечалось. Такие структуры не могут быть хорошо проиндексированы. Я написал и поддержал одну такую ​​систему. К тому времени, когда у нас было 50 000 "сущностей" с 10-100 клавишами каждая, это было МЕДЛЕННО даже на оборудовании среднего уровня).

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

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

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

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

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

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

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

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

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

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

Сколько будет стоить Ford предложить три разных мотора для Taurus или кастомные модификации по запросу?

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

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

Сколько будет стоить Ford предложить три разных мотора для Taurus или кастомные модификации по запросу?

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

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

вы можете начать понимать , почему эта метафора применима.

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

вы можете начать понимать , почему эта метафора применима.

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