代码之家  ›  专栏  ›  技术社区  ›  Younes

查找示例数据库设计的好地方-最佳实践[关闭]

  •  23
  • Younes  · 技术社区  · 14 年前

    我的任务是设计一个数据库,为我们公司存储大量信息。因为任务相当大,包含多个模块,用户应该可以在其中完成任务,所以我担心为这个设计一个好的数据模型。我只是不想最终得到一个设计糟糕的数据库。

    我想有一些关于合同/账单/订单等数据库结构的好例子,以便将它们合并到一个好的关系数据库中。有什么资源可以帮助我举一些例子吗?

    5 回复  |  直到 6 年前
        1
  •  10
  •   HLGEM    6 年前

    在你开始阅读规范化之前,直到你对它没有任何疑问。如果你只是在学校做的,你可能还不知道足够的设计。

    仔细收集每个模块的需求。你需要知道:

    业务规则(特定于应用程序,必须在数据库中强制执行,因为它们必须在所有记录上强制执行,无论源是什么),

    是否存在法律或监管问题(例如HIPAA或萨班斯-奥克斯利法案要求) 安全性(数据需要加密吗?)

    您需要存储哪些数据以及原因(这些数据是否在其他地方可用)

    哪些数据只有一行,哪些数据需要多行

    如何在每个表中强制行的唯一性?您有自然密钥还是需要代理密钥(在几乎所有情况下建议使用代理密钥)

    你需要复制吗?

    你需要审计吗?

    如何将数据输入数据库?它是来自应用程序一次一条记录(甚至来自多个应用程序)还是来自etl工具或另一个数据库的批量插入。

    您是否需要知道谁输入了记录以及何时输入(这在企业系统中极有可能是必需的)。

    你需要什么样的查找表?当您可以使用查找表并将用户限制在值范围内时,数据输入更加准确。

    你需要什么样的数据验证?

    系统大概有多少条记录?您需要知道创建测试数据的规模有多大。

    如何查询数据。您将使用存储过程、orm或动态查询吗?

    在你的设计中要记住一些非常基本的东西。为数据选择正确的数据类型。不要在字符串字段中存储要计算的日期或数字。不要将不适合数学的数字(零件号、邮政编码、电话号码等)存储为字符串数据,因为您可能需要前导零。不要在一个字段中存储多个信息。所以没有逗号连接的列表(这表示需要一个相关的表),当你在做一些事情,如phone1,phone2,phone 3,马上停下来设计一个相关的表。为了数据完整性的目的,请使用外键。

    在整个设计过程中都要考虑数据的完整性。没有完整性的数据是毫无意义和无用的。为性能而设计,这在数据库设计中是至关重要的,并不是过早的优化。数据库不容易重构,因此在第一次获得性能方程中最关键的部分是很重要的。事实上,所有数据库都需要针对数据完整性、性能和安全性进行设计。

    不要害怕有多个连接,正确索引这些连接将执行得很好。不要试图将所有内容都放入实体值类型表中。尽量少用这些。试着从处理数据集的角度来思考,这将有助于你的设计。数据库被优化为在集合中执行任务。

    还有更多,但这已经足够开始消化了。

        2
  •  22
  •   APC    14 年前

    barry williams已经为各种应用程序发布了一个包含大约600个数据模型的库。几乎可以肯定的是,它将为您的所有子系统提供一个“10人入门”。这个图书馆是免费的,所以 check it out .

    听起来这是一个你的组织想要的大型“企业y”应用程序,你似乎是一个数据库初学者。如果可能的话,你应该从一个单一的子系统开始——比如说,订单——然后让它工作。不仅是数据库表的构建,还有一些框架前端。一旦这足够好,再添加另一个相关的子系统,如计费。你不想最后和一个四分五裂的怪物在一起。

    还要确保你有一个像样的数据建模工具。 SQL Power Architect 对于一个免费的工具来说已经足够好了。

        3
  •  2
  •   James    14 年前

    尽量把你的顾虑分开。用户能够更新数据库更多的是一个“应用程序设计”问题。如果您的数据库设计是正确的,那么它应该是一个为它开发良好前端的案例。

    首先要看的是 Normalization . 这是消除任何 冗余 从你的表格中得到的数据。这将有助于保持数据库的整洁,并且只存储与您的需要相关的信息。

        4
  •  2
  •   guettli    10 年前

    数据模型资源手册。

    http://www.amazon.com/Data-Model-Resource-Book-Vol/dp/0471380237/ref=dp_cp_ob_b_title_0

    很重的东西,但很好的通过。总共3卷…

    有很多非常好的通透泛型结构-但它们并不容易,因为它们涵盖了所有的东西;)尽管总是一个很好的起点。

        5
  •  0
  •   Matthieu Napoli    14 年前

    数据库不应该是模型。它用于在工作会话之间保存信息。

    您不应该在数据模型上构建应用程序,而应该在 面向对象模型 这符合商业逻辑。

    对象模型完成后,考虑如何保存和加载它,以及随之而来的所有数据库设计。

    (但显然你的公司只是想让你设计一个数据库?不是应用程序?)