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

Ответ 1

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

Попытайтесь сделать хорошее деловое дело для своей стороны, прежде чем попасть в технический материал.

Ответ 2

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

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

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

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

Ответ 3

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

Попробуйте следующее:

Вы: Какие компании мы не смогли продать?
Продажи: Acme Industries, OCP Corp, бла-бла-бла

Вы: Ну... почему вы не можете сделать еще пару phonecalls?

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

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

Ответ 4

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

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

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

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

Ответ 5

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

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

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

Ответ 6

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

Ответ 7

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

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

Ответ 8

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

Ответ 9

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

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

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

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

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

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

Ответ 10

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

Ответ 11

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

Ответ 12

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

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

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

Ответ 13

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

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

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

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

Возможно, это зависит от поставщика db, но если вы используете Oracle, я бы предпочел, чтобы дорога "просто добавила несколько столбцов" выше объекта-атрибута-стоимости-дороги.

Ответ 14

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

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

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

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

Ответ 15

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

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