我正在处理什么设计理念？
我有两个数据对象 - customers 和 jobs。工作记录是根据客户记录的某些字段创建的。为每次对客户的服务访问创建一个工作记录，每周重复发生一次。
因此，我正在考虑创建作业记录的最佳方式，我可以：
使用服务器功能在后端创建作业记录。并分批创建它们——比如每季度——这样我就可以获得未来 12 周的工作记录。这样我就可以在
jobs表中查询表示层中的任何操作。使用
customers表上的字段在表示层中创建作业，仅在与表示层进行一些交互后创建job记录。 这样，就业机会始终是根据更新的数据创建的。
我认为我应该采用第二种方法，但在处理数据和表示层时，我似乎可能犯了设计违规。
是否有一些概念可以概括此类问题？
--
第一种方法的缺点：服务器功能必须在客户记录发生任何更改后运行，以便更新作业。我想我可以安排该函数每晚运行（cron 作业），这样我每天都会得到更新的记录。但我认为应该有一个更简单的方法。
I have two data objects- customers and jobs. Job records are created based on certain fields of the customer record. A job record is created for each service visit to the customer, which happens on a recurring weekly basis.
So I'm considering the best way to create job records, I can either:
Use a server function to create job records on the backend. And create them in batches- say, quarterly- so I'd have job records for 12 weeks ahead. This way I can just query the
jobstable for any operations in the presentation layer.Use fields on the
customerstable to create jobs in the presentation layer, creating thejobrecord only after some interaction with the presentation layer.
This way, jobs are always created from updated data.
I think I should go with the second approach but it seems like I might be committing a design transgression when it comes to handling data and presentation layers.
Is there some concept that encapsulates this type of problem?
--
Drawback to first approach: The server function would have to run after any changes to the customer record so that jobs are updated. I suppose I could schedule the function to run every night (cron job) so I'm getting updated records every day. But I think there should be a simpler way.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
这是一个意见问题，我怀疑它可能会被删除。
但是，我总是会选择#2。对于#1，您将创建大量空数据记录，这些记录没有任何价值，并且可能会也可能不会被使用。它还使您有机会在保存作业之前向用户提供数据以进行验证。
This is kind of an opinion question, and I suspect it might get removed.
but, I would go with #2, always. with #1 you're creating a lot of empty data records that hold no value and may or may not get used. It also gives you an opportunity to present the data to the user for verification before saving the job.