I tell them I can create a system of tables that allows each client to define their own set of custom fields, but of course that takes more time and money than "just adding a few columns".
I think you should push this option to your bosses since customizability is obviously a feature much in demand. Emphasize that an individually customized (rather than generalized, limited customizability) system for each client means that patches and updates will have to be created for each individual client (leading to longer roll-out times and higher costs); that non-standardized installations mean that HelpDesk tickets will take much longer to close (leading to dissatisfied clients and higher costs); etc.
In other words sell short term pain for long term gain by showing that the cost of their solution far outweighs the cost of your solution.
Salespeople are focussed on making the sale. That's what gets them their commission. They don't care about what comes after. Bosses, however, are focussed on cost. Sell to your bosses and your bosses can sell to the salespeople.
The best way I've found is to show how you can create a new feature out of what they're asking for that you couldn't add with just a couple customized columns. Features are better than customizations, especially when you can charge someone for it.
Try to make a good business case for your side before you get into the technical stuff.
You: Which companies did we fail to sell to? Sales: Acme Industries, OCP Corp, blah blah blah You: Well.... why can't you just make a couple of more phonecalls?
The answer of course is sales isn't that simple. Neither is software development. Unless they really want hours of explanation in regards to architecture and maintenance I suggest they trust your judgement as a software developer.
This is the issue here, trust. You should explain to them they are displaying a lack of trust in your abilities by making these statements.
You can tell them that a poorly designed database means that in the long term:
it will take longer for them to retrieve their data - do they really want to wait and wait?
it will be harder and take longer to design queries to generate reports - again, if they need that query tomorrow, do they want to be told that it's still being worked on?
it will be a nightmare to maintain, with error prone queries more likely to be written.
If they're sales people and bean counters, then they will definitely understand the almighty dollar (pound, euro, etc.). Can you demonstrate that the time spent to maintain these extra columns doesn't justify the added sales?
Be very careful here and make sure your argument makes sense. I've found myself resistant in the past to doing customizations more because I didn't want to ugly up my pretty little domain model than because it would really be that difficult to maintain. A decent analysis will help you determine why you're resisting the customization.
Remember - the bottom line is that you need to keep clients happy in order to stay in business. We thoughtful developers can sometimes lose sight of that in our quest to make things maintainable and simple.
If you're in the business of selling a product along with customizations, the product needs to support customizations without having to fork the build each time they sell it.
Sounds like you've tried explaining that, to no avail. Instead, try estimating the cost of adding your "customization the right way" for one table with maintaining, say, half a dozen versions of the product with different customizations, and fixing a bug across off of them. My bet is that they will see that they're pretty soon money ahead having a unified codebase and schema. And a developer who isn't driven insane.
Tell them that when people make a car and then they want a model that goes faster and does more than the previous, they usually don't add another engine.
The problem is that "We are trying to keep the database well normalized" is almost certainly the wrong answer - it plays back the ball into the court of mistrust and cross-purposes.
You have got to turn focus back onto the end goal, how best to meet that end goal (perhaps in several releases) and what it will cost in the short and long term. I've seen mention of technical debt in answers and cost estimates should take those factors into consideration.
It might not be a bad idea to "just add another column?". You really haven't given the entire business case. On the other hand, they have challenged your negative response with an ignorant technical question. That doesn't get to the heart of helping you understand the requirement because they didn't like hearing "no". (I'd like to know what the original statement of the problem was.)
Making the database normalized is a technical problem and has no bearing on the requirements the system must satisfy - it is a system design principle which you use to deliver systems with certain properties like maintainability. But a maintainable systems which don't meet user needs have zero value, while unmaintainable systems which do meet user needs have non-zero value (which might be exceeded by the cost of maintenance - which is a business problem). Whether EAV or some other mechanism is required is not really the point either - that just causes system complexity or cost to increase.
If the requirements are too expensive to ever implement, then that's part of the business case. You haven't told us enough about the architecture or the type of entities these tables model. Say you have 100 clients. There may be overlap in columns in a particular entity. Just as many as 95% of clients will never use the optional Billing-Address or a Middle-Name column, that doesn't mean those columns are left out - not only that, they are often in an original design! Alternatively, if this is a Products table and every client wants many special columns and there is no overlap, you might need a user-defined field system (EAV/XML/tag - the design will have to match the requirements) instead in order to maintain a cohesive system design.
I have rarely found business to ignore a technical debt argument - particularly if a proposed solution can be shown to meet the user needs and flexibility can become a selling point. What I have found is that business will often prefer if you present solution choices as quickly and thoroughly as possible without spending more time explaining why something can't be done or how much it's going to cost than it would take to buckle down in a couple afternoons and actually getting the work done.
I've never tried this myself, but I've thought about it: draw an analogy to the legal system. Legal loopholes exist because law makers try to patch the system with lazy kludges. The software equivalent is bugs, security holes, etc. The only way around these problems is careful planning and hard work.
Make them understand how much that costs in development time, will this change require 1 or two developers time? what about testing? if complex requests cost more then the company as whole is making less on the job. The account / project manager should be the middleman who's job it is to buffer these type of requests.
You won't get anywhere explaining it to them in technical terms. You need a metaphor. Tailor it to the person you're talking to, if you can. If he/she is a car freak, get them to think in terms of engine modifications. How much would it cost Ford to offer three different motors in the Taurus, or custom mods on demand?
Once they accept that comparison, even if they don't fully understand it, you can begin to get into why the metaphor applies.
There's another great way to help them see it your way- take some time to see it their way as well. When your paycheck depends on giving the customer what they want, you don't care what the propellerhead in Engineering tells you. If you're getting a lot of requests for customization, you should consider the architectural and strategic approaches to delivering those customizations, wherever possible.
乍一看这可能很可怕，但它也可能是一个折中办法。有相当大的空间可以根据每个客户进行定制，而无需 a)“仅添加一列”并扰乱应用程序或开发过程，或 b) 实施可能缓慢的通用系统。不过，您只能获得有限的可感知性，并且缺乏自记录的列名称（但可以根据需要自定义列描述）。
To expand on tuinstoel's suggestion (avoid generic entity-attribute-value structures): While I generally like this structure for light use, excessive (whatever that means) usage will degrade performance as noted. Such structures cannot be well indexed. I wrote and supported one such system. By the time we had 50,000 "entities" each with 10-100 keys it was SLOW even on midrange hardware).
However, they are very useful and fairly easy to implement. So if there's a need for many arbitrary "extra fields" to be added on a per customer basis, then it may make the most sense.
Another possible option might be to add a number of unused generic column in appropriate tables to be used by clients for their own purposes. Some enterprisy applications do just this. A Sales table might have ten or twenty CUSTCODE01 to CUSTCODE10 columns which each deployment of the application can use in different, wholly custom way.
This may at first look horrid, it may also be a happy medium. There is a fair amount of room to customize on a per-customer basis without a) "just adding a column" and disrupting the application or development process, or b) implementing a potentially slow generic system. You only get a limited amount of felxablity, though, and there is a lack of self-documenting column names (but column descriptions can be customized as needed).
...I tell them I can create a system of tables that allows each client to define their own set of custom fields, but of course that takes more time and money....
Looks like you want to build some kind of generic data model? Entity-attribute-value...?
Those generic models are often real slow, they can't be indexed properly and confuse the query optimizer. It is often better to just add some columns.
Do some very thorough benchmarking before going the generic road.
Maybe it is db vendor dependent but if you use Oracle, I would prefer the 'just add some columns' road above the entity-attribute-value-road.
You can explain this problem drawing a comparison with a library. There are many books. Small one and big one, thin and thick ones - everybody can imagine that. Now if you want to store more information somewhere it would be rather simpler to add some new pages to a book than enlarge some single pages - if there are several pages of a book larger than the others, this not very robust and how would one find this information if it has no entry in the index of contens? Maybe it is better to store the new additional information in a further book, a new one with a particular structur. 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.
发布评论
评论（15）
我认为你应该把这个选项推给你的老板，因为可定制性显然是一个非常需要的功能。强调为每个客户端单独定制（而不是通用的、有限的可定制性）系统意味着必须为每个客户端创建补丁和更新（导致更长的推出时间和更高的成本）；非标准化安装意味着服务台票证将需要更长的时间才能关闭（导致客户不满意和更高的成本）；换句话说
，通过证明他们的解决方案的成本远远超过你的解决方案的成本，以出售短期痛苦来换取长期收益。
销售人员专注于销售。这就是他们获得佣金的原因。他们不关心之后发生的事情。然而，老板们关注的是成本。卖给你的老板，你的老板也可以卖给销售人员。
I think you should push this option to your bosses since customizability is obviously a feature much in demand. Emphasize that an individually customized (rather than generalized, limited customizability) system for each client means that patches and updates will have to be created for each individual client (leading to longer roll-out times and higher costs); that non-standardized installations mean that HelpDesk tickets will take much longer to close (leading to dissatisfied clients and higher costs); etc.
In other words sell short term pain for long term gain by showing that the cost of their solution far outweighs the cost of your solution.
Salespeople are focussed on making the sale. That's what gets them their commission. They don't care about what comes after. Bosses, however, are focussed on cost. Sell to your bosses and your bosses can sell to the salespeople.
我发现的最好方法是展示如何根据他们的要求创建一个新的功能，而您无法仅通过几个自定义列来添加这些功能。功能比定制更好，尤其是当你可以向某人收费时。
在讨论技术问题之前，请尝试为您的一方制定一个良好的业务案例。
The best way I've found is to show how you can create a new feature out of what they're asking for that you couldn't add with just a couple customized columns. Features are better than customizations, especially when you can charge someone for it.
Try to make a good business case for your side before you get into the technical stuff.
啊..一点知识是一件危险的事情。
试试这个：
你：我们未能向哪些公司销售产品？
销售： Acme Industries、OCP Corp，等等等等
你：嗯......你为什么不能再打几个电话呢？
答案当然是销售没那么简单。软件开发也不是。除非他们真的想要关于架构和维护的大量解释，我建议他们相信你作为软件开发人员的判断。
这就是问题所在，相信。您应该向他们解释，做出这些陈述表明他们对您的能力缺乏信任。
Ah.. a little knowledge is a dangerous thing.
Try this one:
You: Which companies did we fail to sell to?
Sales: Acme Industries, OCP Corp, blah blah blah
You: Well.... why can't you just make a couple of more phonecalls?
The answer of course is sales isn't that simple. Neither is software development. Unless they really want hours of explanation in regards to architecture and maintenance I suggest they trust your judgement as a software developer.
This is the issue here, trust. You should explain to them they are displaying a lack of trust in your abilities by making these statements.
您可以告诉他们，设计不佳的数据库意味着从长远来看：
他们将需要更长的时间来检索数据 - 他们真的想等待并等待吗？
设计查询来生成报告将会更加困难并且需要更长的时间 - 同样，如果他们明天需要该查询，他们是否想被告知它仍在处理中？
维护起来将是一场噩梦，因为更有可能编写容易出错的查询。
维护起来将是一场噩梦，因为
You can tell them that a poorly designed database means that in the long term:
it will take longer for them to retrieve their data - do they really want to wait and wait?
it will be harder and take longer to design queries to generate reports - again, if they need that query tomorrow, do they want to be told that it's still being worked on?
it will be a nightmare to maintain, with error prone queries more likely to be written.
如果他们是销售人员和精算师，那么他们肯定会了解万能的美元（英镑、欧元等）。您能否证明，维护这些额外列所花费的时间并不能证明增加的销售额是合理的？
这里要非常小心，并确保你的论点是有道理的。我发现自己过去更不愿意进行定制，因为我不想让我漂亮的小域模型变得丑陋，而不是因为它真的很难维护。适当的分析将帮助您确定拒绝定制的原因。
请记住 - 最重要的是，您需要让客户满意才能维持业务。我们深思熟虑的开发人员有时会在追求使事情变得可维护和简单的过程中忽视这一点。
If they're sales people and bean counters, then they will definitely understand the almighty dollar (pound, euro, etc.). Can you demonstrate that the time spent to maintain these extra columns doesn't justify the added sales?
Be very careful here and make sure your argument makes sense. I've found myself resistant in the past to doing customizations more because I didn't want to ugly up my pretty little domain model than because it would really be that difficult to maintain. A decent analysis will help you determine why you're resisting the customization.
Remember - the bottom line is that you need to keep clients happy in order to stay in business. We thoughtful developers can sometimes lose sight of that in our quest to make things maintainable and simple.
谷歌“技术债务”；向他们展示结果。
Google "technical debt"; Show them the results.
如果您从事销售产品和定制产品的业务，则该产品需要支持定制，而不必在每次销售时分叉构建。
听起来你已经尝试过解释这一点，但没有成功。相反，尝试估计为一张表添加“正确的自定义方式”的成本，并维护具有不同自定义的产品的六个版本，并修复其中的错误。我敢打赌，他们很快就会发现，拥有统一的代码库和模式，他们很快就能获得资金。以及一个没有被逼疯的开发者。
If you're in the business of selling a product along with customizations, the product needs to support customizations without having to fork the build each time they sell it.
Sounds like you've tried explaining that, to no avail. Instead, try estimating the cost of adding your "customization the right way" for one table with maintaining, say, half a dozen versions of the product with different customizations, and fixing a bug across off of them. My bet is that they will see that they're pretty soon money ahead having a unified codebase and schema. And a developer who isn't driven insane.
告诉他们，当人们制造汽车时，他们想要一种比以前更快、功能更多的车型，他们通常不会添加另一个发动机。
Tell them that when people make a car and then they want a model that goes faster and does more than the previous, they usually don't add another engine.
问题在于，“我们正在努力使数据库保持良好的标准化”几乎肯定是错误的答案 - 它会导致不信任和交叉目的。
您必须将注意力重新转移到最终目标上，如何最好地实现该最终目标（可能在多个版本中）以及短期和长期的成本。我在答案中看到提到技术债务，成本估算应该考虑这些因素。
“只是添加另一列？”可能不是是一个坏主意。您确实没有给出整个业务案例。另一方面，他们用一个无知的技术问题对你的负面回应提出了质疑。这并不能触及帮助您理解要求的核心，因为他们不喜欢听到“不”。 （我想知道问题的原始陈述是什么。）
使数据库规范化是一个技术问题，与系统必须满足的要求无关 - 这是一个系统设计原则，您可以使用它来交付系统某些属性，例如可维护性。但是，不能满足用户需求的可维护系统的价值为零，而满足用户需求的不可维护的系统则具有非零价值（维护成本可能会超过该价值，这是一个业务问题）。是否需要 EAV 或其他机制也不是真正的重点 - 这只会导致系统复杂性或成本增加。
如果这些要求的实施成本太高，那么这就是业务案例的一部分。您还没有告诉我们足够的有关这些表建模的实体的体系结构或类型的信息。假设您有 100 个客户。特定实体中的列可能存在重叠。多达 95% 的客户永远不会使用可选的帐单地址或中间名列，这并不意味着这些列被遗漏 - 不仅如此，它们通常采用原始设计！或者，如果这是一个产品表，并且每个客户都需要许多特殊列并且没有重叠，那么您可能需要一个用户定义的字段系统（EAV/XML/标签 - 设计必须符合要求），以便保持有凝聚力的系统设计。
我很少发现企业忽视技术债务论点——特别是如果所提出的解决方案可以满足用户需求并且灵活性可以成为一个卖点。我发现，如果您尽可能快速、彻底地提出解决方案选择，而不花更多时间解释为什么某件事无法完成或需要花费多少时间，那么企业通常会更喜欢您花在几个时间里的时间下午并实际完成工作。
The problem is that "We are trying to keep the database well normalized" is almost certainly the wrong answer - it plays back the ball into the court of mistrust and cross-purposes.
You have got to turn focus back onto the end goal, how best to meet that end goal (perhaps in several releases) and what it will cost in the short and long term. I've seen mention of technical debt in answers and cost estimates should take those factors into consideration.
It might not be a bad idea to "just add another column?". You really haven't given the entire business case. On the other hand, they have challenged your negative response with an ignorant technical question. That doesn't get to the heart of helping you understand the requirement because they didn't like hearing "no". (I'd like to know what the original statement of the problem was.)
Making the database normalized is a technical problem and has no bearing on the requirements the system must satisfy - it is a system design principle which you use to deliver systems with certain properties like maintainability. But a maintainable systems which don't meet user needs have zero value, while unmaintainable systems which do meet user needs have non-zero value (which might be exceeded by the cost of maintenance - which is a business problem). Whether EAV or some other mechanism is required is not really the point either - that just causes system complexity or cost to increase.
If the requirements are too expensive to ever implement, then that's part of the business case. You haven't told us enough about the architecture or the type of entities these tables model. Say you have 100 clients. There may be overlap in columns in a particular entity. Just as many as 95% of clients will never use the optional Billing-Address or a Middle-Name column, that doesn't mean those columns are left out - not only that, they are often in an original design! Alternatively, if this is a Products table and every client wants many special columns and there is no overlap, you might need a user-defined field system (EAV/XML/tag - the design will have to match the requirements) instead in order to maintain a cohesive system design.
I have rarely found business to ignore a technical debt argument - particularly if a proposed solution can be shown to meet the user needs and flexibility can become a selling point. What I have found is that business will often prefer if you present solution choices as quickly and thoroughly as possible without spending more time explaining why something can't be done or how much it's going to cost than it would take to buckle down in a couple afternoons and actually getting the work done.
我自己从未尝试过，但我想过：与法律体系进行类比。法律漏洞的存在是因为立法者试图用懒惰的拼凑来修补系统。软件等同于错误、安全漏洞等。解决这些问题的唯一方法是仔细规划和努力工作。
I've never tried this myself, but I've thought about it: draw an analogy to the legal system. Legal loopholes exist because law makers try to patch the system with lazy kludges. The software equivalent is bugs, security holes, etc. The only way around these problems is careful planning and hard work.
让他们了解这会花费多少开发时间，此更改是否需要 1 到 2 名开发人员时间？测试怎么样？如果复杂的请求成本更高，那么整个公司的工作收入就会减少。客户/项目经理应该是中间人，其职责是缓冲这些类型的请求。
Make them understand how much that costs in development time, will this change require 1 or two developers time? what about testing? if complex requests cost more then the company as whole is making less on the job. The account / project manager should be the middleman who's job it is to buffer these type of requests.
你无法用技术术语向他们解释。你需要一个比喻。如果可以的话，根据你正在交谈的人量身定制。如果他/她是汽车迷，让他们考虑发动机改装。福特在金牛座上提供三种不同的发动机或按需定制改装需要花费多少钱？
一旦他们接受了这种比较，即使他们没有完全理解它，您也可以开始了解为什么使用这个比喻。
还有另一种好方法可以帮助他们以您的方式看待问题——也花一些时间以他们的方式看待问题。当你的薪水取决于向客户提供他们想要的东西时，你并不关心工程部门的螺旋桨头告诉你什么。如果您收到大量定制请求，则应尽可能考虑交付这些定制的架构和战略方法。
You won't get anywhere explaining it to them in technical terms. You need a metaphor. Tailor it to the person you're talking to, if you can. If he/she is a car freak, get them to think in terms of engine modifications. How much would it cost Ford to offer three different motors in the Taurus, or custom mods on demand?
Once they accept that comparison, even if they don't fully understand it, you can begin to get into why the metaphor applies.
There's another great way to help them see it your way- take some time to see it their way as well. When your paycheck depends on giving the customer what they want, you don't care what the propellerhead in Engineering tells you. If you're getting a lot of requests for customization, you should consider the architectural and strategic approaches to delivering those customizations, wherever possible.
扩展 tuinstoel 的建议（避免通用的实体属性值结构）：虽然我通常喜欢这种结构的轻度使用，但过度（无论这意味着什么）使用会降低性能，如前所述。这样的结构无法被很好地索引。我编写并支持了一个这样的系统。当我们拥有 50,000 个“实体”，每个实体有 10-100 个键时，即使在中端硬件上，速度也很慢）。
然而，它们非常有用并且相当容易实现。因此，如果需要为每个客户添加许多任意“额外字段”，那么这可能是最有意义的。
另一种可能的选择可能是在适当的表中添加许多未使用的通用列，以供客户端用于自己的目的。一些企业应用程序就是这样做的。 Sales 表可能有十到二十个 CUSTCODE01 到 CUSTCODE10 列，应用程序的每个部署都可以以不同的、完全自定义的方式使用这些列。
乍一看这可能很可怕，但它也可能是一个折中办法。有相当大的空间可以根据每个客户进行定制，而无需 a)“仅添加一列”并扰乱应用程序或开发过程，或 b) 实施可能缓慢的通用系统。不过，您只能获得有限的可感知性，并且缺乏自记录的列名称（但可以根据需要自定义列描述）。
To expand on tuinstoel's suggestion (avoid generic entity-attribute-value structures): While I generally like this structure for light use, excessive (whatever that means) usage will degrade performance as noted. Such structures cannot be well indexed. I wrote and supported one such system. By the time we had 50,000 "entities" each with 10-100 keys it was SLOW even on midrange hardware).
However, they are very useful and fairly easy to implement. So if there's a need for many arbitrary "extra fields" to be added on a per customer basis, then it may make the most sense.
Another possible option might be to add a number of unused generic column in appropriate tables to be used by clients for their own purposes. Some enterprisy applications do just this. A Sales table might have ten or twenty CUSTCODE01 to CUSTCODE10 columns which each deployment of the application can use in different, wholly custom way.
This may at first look horrid, it may also be a happy medium. There is a fair amount of room to customize on a per-customer basis without a) "just adding a column" and disrupting the application or development process, or b) implementing a potentially slow generic system. You only get a limited amount of felxablity, though, and there is a lack of self-documenting column names (but column descriptions can be customized as needed).
...我告诉他们我可以创建一个表格系统，允许每个客户定义自己的一组自定义字段，但这当然需要更多的时间和金钱...
看起来你想要建立某种通用数据模型？实体-属性-值...？
这些通用模型通常非常慢，它们无法正确索引并使查询优化器感到困惑。通常最好只添加一些列。
在走通用之路之前，先做一些非常彻底的基准测试。
也许它依赖于数据库供应商，但如果您使用 Oracle，我更喜欢实体属性值道路之上的“仅添加一些列”道路。
...I tell them I can create a system of tables that allows each client to define their own set of custom fields, but of course that takes more time and money....
Looks like you want to build some kind of generic data model? Entity-attribute-value...?
Those generic models are often real slow, they can't be indexed properly and confuse the query optimizer. It is often better to just add some columns.
Do some very thorough benchmarking before going the generic road.
Maybe it is db vendor dependent but if you use Oracle, I would prefer the 'just add some columns' road above the entity-attribute-value-road.
您可以通过与库进行比较来解释这个问题。有很多书。小的和大的，薄的和厚的——每个人都可以想象。现在，如果您想在某处存储更多信息，则向书中添加一些新页面比放大某些单页要简单得多 - 如果一本书的几页比其他页大，这不是很稳健，人们将如何找到该信息是否在内容索引中没有条目？
也许最好将新的附加信息存储在另一本书中，一本具有特定结构的新书。
想象一下，如果图书馆的全部内容都写在一本厚厚的书中，人们将如何获取信息？在你找到你想要的东西并将书放回原处之前，没有人能找到任何东西......如果你能够携带这本巨大的书。
如果您只想知道一个人的出生日期，为什么要检索整个 Livestory？
提到的人不必了解数据库的架构，但他们应该信任你。您可以对其进行组织，以便他们可以将信息放入数据库的这个大洞中，并在需要时快速可靠地取回。
You can explain this problem drawing a comparison with a library. There are many books. Small one and big one, thin and thick ones - everybody can imagine that. Now if you want to store more information somewhere it would be rather simpler to add some new pages to a book than enlarge some single pages - if there are several pages of a book larger than the others, this not very robust and how would one find this information if it has no entry in the index of contens?
Maybe it is better to store the new additional information in a further book, a new one with a particular structur.
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.