对核心数据中的重复事务进行建模
我很难为核心数据中的重复交易方案提出概念模型。到目前为止，我有：
1）一个 BillMaster 实体（上面引用），它具有“到期日”“标题”等属性。
2) BillEntry 实体，它基本上是主帐单的子实体，即您将在日历上看到的实际帐单。这些将指向到期日、标题的主数据，并且还将跟踪该账单实例是否已支付。
问题是，我需要复制这些主条目，并以一种高效的方式创建重复的子条目，每次账单重复创建一个。我不确定这个条目的生成应该何时真正发生，以及它应该持续多久。我也不想在不必要的时候意外地重新生成这些。也许还有一种我没有想到的更聪明的方法来对此进行建模。
如果你们有任何建议，或者可能有一些很好的阅读材料来讨论像这样的概念性问题，我愿意接受任何事情。总的来说，我对核心数据有相当好的理解（相当好，无论如何都不是专家），但其中一些更复杂的模型仍然让我感到困惑。
I'm having a hard time coming up with a conceptual model for a recurring transaction scheme in Core Data. So far I have:
1) A BillMaster entity (referenced above) which has attributes like "due date" "title" etc.
2) A BillEntry entity which is basically the children of the master bill, the actual bills you would see on the calendar. These would point to the master data for due date, title, and would also keep track of whether this instance of the bill has been paid or not.
The problem is, I'm going to need to duplicate these masters and create the recurring children entries in a way that's efficient, one for every time the bill recurs. I'm not sure when this entry generation should actually occur, and how far out it should go for. I also don't want to accidentally re-generate these when it's not necessary to. Maybe there's even a smarter way to model this out that I'm not thinking of.
If there are any suggestions any of you have, or maybe some good reading material that goes over conceptual things like this, I'm open to anything. I have a fairly good understanding of Core Data in general (fairly good, no expert by any means) but some of these more complex models still throw me for a loop.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
大约有 5 个不同的“核心数据”出现。苹果系统？
但无论如何，您的问题似乎是通用的，而不是特定于核心数据的。基本上，假设 BillMaster 是正确的，在您的应用程序中的某个位置，您需要一个“生成账单”按钮。只需将 BillMaster投影 到 BillEntry 中即可，无论 BillMaster 目前是否可计费。
There's about 5 different "Core Data" that comes up. MacOS ?
But anyway, it seems that your question is generic, not specific to Core Data. Basically, assuming the BillMaster is correct, somewhere in your app, you need a button for "Generate Bills". Simply project BillMaster into BillEntry, for whatever BillMasters are billable right now.