基于表设计的类建模

Question

这是人们通常设计课程的方式吗？ 一类 = 1 个表。 包含另一个表的外键的表怎么样？

假设我有以下内容：

PersonTable
---------------
person_id
name

PersonMapTable
---------------
map_id
type_id (fk)
person_id

PersonTypeTable
-------------------
type_id
description
parent_type_id

AddressTable
-------------------
address_id
address1
address2
city
state
zip

AddressMapTable
-----------
address_map_id
address_id
person_id

好的做法包括为每个表创建一个类吗？ 如果是这样，在没有 orm 的情况下将此类类加载/保存回数据库的最佳实践是什么？ 一个简单的代码示例会非常有帮助

Answer 1

我建议阅读 Martin Fowler 的 企业应用程序架构模式，其中有几种映射模式类和表。

Answer 2

我认为每张桌子一个对象不一定是一个好的设计。 很难给出一个放之四海而皆准的规则，但对象可以更丰富、更细粒度。 数据库可以因不适用于对象的原因而被非规范化。 在这种情况下，您将拥有比表更多的对象。

您的案例将包括 1:1 和 1:m 关系：

public class Person
{
    // 1:m
    private List<your.namespace.Map> maps; 
}

public class Map
{
    // 1:1
    private your.namespace.Type;
}

Answer 3

在大多数情况下，我倾向于将表映射到实体，但这不是一个硬性规则。 有时，在某些情况下，所讨论的特定实体的存储库最好处理围绕特定实体的一般问题，这意味着它将交叉处理其他表，而不需要这些表特别需要作为实体存在。

我从不做的事情（除了在非常具体的计划情况下，总是需要使用实体检索依赖数据）是将一个实体或实体集合设置为另一个实体的属性。 相反，该实体要么可以通过其 ID 发现，该 ID 要么是父实体的属性，要么可以通过与父实体相关的关联存储库发现。

如果我需要将另一个实体的子实体或实体捆绑在一起，我将使用“info”帮助程序类将所有所需的数据组合在一起。 例如，如果我有一个实体类 Widget 并且它有一个子 Part 对象的集合，那么我将创建一个 WidgetInfo 类，它将包含 Widget 实例作为属性，并包含 Part 对象集合作为另一个属性。

这样，所有实体类都尽可能保持轻量级，并且永远不会假设需要加载依赖数据。 它还可以保持存储库模型干净，而不会迫使您进入混乱的 ORM 领域，如果您在实体类上创建子对象集合，通常会出现这种情况。 如果您在没有 ORM 的情况下执行此操作，那么您最终会遇到何时加载子项以及何时假设子项已加载或尚未加载的混乱问题。

Answer 4

我不会说我总是每张桌子都有班级，特别是当你有多对多关系时。 根据您上面的表格，我将有 2 个课程...我不确定为什么您同时拥有 id 和 person_type_id，对我来说它们是相同的东西，但这里是课程。

Person
{
   public int Id { get; set; }

   public string Name { get; set; }

   public List<PersonType> { get; set; }
}

PersonType
{
   // I would discourage from using Type as property name as it is a keyword...
   public string [Type] { get; set; }
}

Answer 5

除非您的用户是数据输入员，否则通常认为从用例/用户故事中设计类会更好。 即使数据库已经存在。

原因？ 用户很容易最终认为他们的工作是使用软件，而不是期望软件帮助他们完成工作。

显然它们需要在某个点相交。 我同意福勒的书是一个很好的起点。 但我认为他会强化这一观点。

如果您想要一个可以帮助您正确获取类和数据库的建模视角，请考虑对象角色建模。

Answer 6

如果您计划使用对象关系映射 (ORM)，这可能会影响您的表设计。 例如，Hibernate 不喜欢同一棵树中的混合继承映射策略。

由于您明确表示您不会使用 ORM，因此您可以遵循传统的数据库设计原则。 这通常意味着从每个类一个表开始，规范化为第三范式（在此处阅读有关数据库规范化的信息），然后反规范化以满足性能约束（在此处阅读有关反规范化的信息）。

关于如何在不使用 ORM 的情况下加载和保存对象的问题，常见的策略是使用数据访问对象 (DAO）。 这是一个简单的例子：

public interface ICustomerDao
{
  public void insert(Customer customer) throws CustomerDaoException;
  public void update(long id, Customer customer) throws CustomerDaoException;
  public void delete(long id) throws CustomerDaoException;
  public Customer[] findAll() throws CustomerDaoException;
  public Customer findByPrimaryKey(long id) throws CustomerDaoException;
  public Customer[] findByCompany(int companyId) throws CustomerDaoException;
}

您没有指定您使用的语言，但无论如何您可能会发现 这个使用 Java 泛型的示例对于 DAO 很有用。

Answer 7

好的做法包括
为每个表创建一个类？ 如果
那么，最佳实践是什么
将此类类加载/保存回
没有 orm 的数据库？

您正在使用 ORM。 您正在将对象映射到关系表。 是否使用预构建的库来执行此操作由您决定。 如果不这样做，您实际上将自己实现一个，尽管可能没有现有 ORM 的所有花哨功能。

执行此操作的两种最常见方法是 ActiveRecord 模式和数据映射器模式。 每个都有其优点和缺点。

使用 ActiveRecord 模式，您可以定义类，其属性为您定义表列。 此类的每个实例对应于数据库中的一行，通过创建（并保存）新实例，您可以在数据库中创建新行。 有关详细信息，请访问：http://en.wikipedia.org/wiki/Active_record_pattern

在数据映射器模式中，您为每个表定义表对象，并编写将表的列分配给现有类的映射器函数。 SQLAlchemy 默认使用此模式（尽管有 ActiveRecord 类型扩展模块，它们使 SQLAlchemy 的功能适应不同的接口。此模式的简要介绍可以在 SQLAlchemy 的文档中找到：http://www.sqlalchemy.org/docs/05/ormtutorial.html（从头开始阅读，但不包括标题为“以声明方式一次性创建表、类和映射器”的部分解释了使用 SQLAlchemy 的 ActiveRecord）

。在可读性方面有一个好处，ActiveRecord 类的声明性本质上可以有效地充当数据库模式的清晰、直接的文档，

数据映射器模式为您提供了更大的灵活性，让您能够更灵活地映射数据到类。与表和类之间或多或少的一对一关系无关。 它还将持久层与业务代码分开，这意味着您可以在以后根据需要更换其他持久机制。 这也意味着您可以更轻松地测试您的类，而无需设置数据库来支持它们。

有关 SQLAlchemy 映射器配置的更深入讨论，请查看 http://www.sqlalchemy。 org/docs/05/mappers.html。 即使您不打算使用像 SQLAlchemy 这样的库，文档也应该帮助您了解在将类映射到数据库表时可能需要考虑的一些选项。

Answer 8

这种从数据库到类的观点方法很可能会导致您很快地编写大量代码。 然而，这段代码的很大一部分可能没有任何用处或者需要一些严重的修改。 换句话说，您可能会构建与您的显示和工作流程不匹配的特定类。

首先，考虑您的应用程序、用户的需求、一般工作流程等。实际上想出一些看起来可行的东西（即模拟您的显示器）。

专注于使用显示所需的类，并根据这些需求对存储进行建模（数据库设计）。 您可能只有几个直板类，因为您的大多数类自然会为您的显示提供解决方案。

祝你好运。