我应该将默认行为存储在数据中吗？
默认情况下，我将发票发送到客户的帐单地址。当客户更喜欢通过电子邮件发送发票时，我会将所需的地址存储在“发票交付首选项”表中。
我还应该在此处存储默认行为的实例吗？也就是说，对邮寄发票没有问题的客户是否应该在此表中包含包含其唯一帐单地址的行？
类似的问题得到了回答“否”，但它们的默认值实际上是相同的 - 对我来说，这只是默认的过程，因为客户有独特的帐单地址。
我担心的是，如果我想在将这些实例存储为行后更改默认行为，我必须更新大量实例。现在，我可以通过告诉 1 COBOL 例程获取帐单地址以外的其他内容并将其发送到打印/电子邮件服务器来更改默认行为。
结果：我决定将默认行为的实例存储在表中，并添加一个“源”列，将每一行标识为“系统默认”或“客户偏好” 这整合了信息，并使开票流程保持一致，至少从“使用的表格”的角度来看是这样。
By default I send invoices to the customer’s billing address. When a customer prefers an e-mailed invoice, I store the desired address in a “Invoice Delivery Preferences” table.
Should I also be storing instances of the default behavior here? That is, should customers who are fine with the mailed invoices have rows with their unique billing addresses in this table?
A similar question was answered “No”, but their defaults were actually identical – for me, it’s only the process that’s a default, since customers have unique billing addresses.
My concern is that if I wanted change my default behavior after storing these instances as rows, I’d have to update a huge number of them. Right now I could change default behavior by telling 1 COBOL routine to grab something other than the billing address, and send that to the print/e-mail server.
Outcome: I decided to store the instances of default behavior in the table, and add a "Source" column identifying each row as "System Default" or "Customer Preference" This consolidated the information, and made the invoicing process consistent, at least from a "tables used" perspective.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
对于以一种且仅一种方式运作的流程，有一些话要说。
仅以一种方式工作的流程通常更容易构建、更容易排除故障、更容易维护并且更容易审查。 （您通常可以只看代码并说，“是的。没错。”）
虽然仅这一个问题的认知负荷很低，但现实世界的系统可能有数百或数千个类似的设计点。在复杂的系统中采用通用方法会带来巨大的回报。
这是一种“在确保你有一个非常非常好的篮子之后，将所有鸡蛋放在一个篮子里”的策略。
但由于 SQL 数据库非常灵活，因此您可能只需创建一个从两个表中选择正确地址的视图即可获得很多好处。然后所有应用程序代码都可以读取该视图。为了跟上不断变化的需求，只需更改视图即可。
There's something to be said for a process that works one and only one way.
Processes that work one and only one way are usually easier to build, easier to troubleshoot, easier to maintain, and easier to review. (You can often just look at the code and say, "Yup. That's right.")
Although the cognitive load is low with just this one question, a real-world system could have hundreds or thousands of similar design points. Taking a common approach pays off substantially in complex systems.
This is kind of a "Put all your eggs in one basket, after you've made sure you've got a really, really good basket" strategy.
But because SQL databases are so flexible, you can probably get a lot of the benefits from just creating a view that selects the right addresses from the two tables. Then all application code could just read that view. To keep up with changing requirements, just change the view.