这里的哲学问题当涉及到 OOP 和数据库，特别是类由数据库备份的程序时，解决这个问题的最佳方法是什么？例如，一个团队类可能有一组玩家。该程序将在启动时从数据库中加载所有团队数据，在内存中进行所有操作，然后在关闭时写入数据库。还是在发生更改时将每个数据操作写入数据库更好？如果这是更好的方法，为什么首先将数据加载到内存中？
另一个担忧是，在我看来，数据库以一种重要的方式打破了标准的 OOP。使用我的包含球员集合的球队类，使用 OOP，球员类不需要有一个属性来保存球队名称。玩家将从其所属的团队类别中获得团队名称。现在，要将球员保存在数据库中，每个球员记录都必须有一列用于球队名称（或球队 ID，但这是同一件事）。
换句话说，如果你需要一个 GetAllPlayers() 方法，你是让它成为团队类中的成员方法，从内存中返回集合中的所有玩家，还是在玩家类中创建一个静态方法来获取所有数据库中的玩家？
有人对如何回答这些问题有任何提示吗？
我已经有一段时间没有上编程课了。任何人都知道一本很好的教科书可以理解这里的最佳方法吗？
数据库以更基本的方式打破了面向对象。（或者对象破坏了关系模型。这取决于您是中层 OO 人员还是 DBA。）
关系数据库是根据定义设置的，本质上是声明性的。面向对象的语言是基于对象实例的。由于“对象关系阻抗不匹配”，使两者一起工作很困难。这就是为什么你会看到这么多 ORM 解决方案（例如 TopLink、Hibernate 等）的原因。它们都在试图欺骗面向对象的程序员，让他们认为他们只需要处理对象而不用担心关系数据库。
无论您如何实现它，我认为持久性应该与模型对象分开。我通常将关系代码放在基于接口的数据访问层中。这样模型对象就不必知道它们是否被持久化，并且我将 CRUD 操作隔离在一个包中。
至于推荐阅读，我将提供 Fowler 的企业应用架构模式供您参考。
The best solution for this scenario really depends on a huge number of variables. Typically, a "layered" approach is considered the best bang for your buck in OO languages, but even that has a nearly infinite number of permutations based on the priority of each concern the application must address.
Your representational objects (Player, Team, etc.) should typically not be involved in database operations, as that responsibility would belong to your data access layer, for example.
A good way to approach learning the object-oriented mindset is to take a look at some design patterns. A good "easy read" book on that topic that I recommend is "Head First Design Patterns." It's in Java, and gives a variety of angles on each topic it covers. In my opinion, it serves as a good bridge between the level of the "Dummies" books and the level of the more abstract/theoretical books.