MySQL的数据库架构设计，建议？

时间：2010-11-16 12:52:13

标签： mysql database-design

所以，有机会做我的第一个“真正的”数据库，只是想着自己应该考虑什么......有什么建议吗？

  • 选择数据库（使用MySQL）
  • 根据需要选择数据库引擎（使用MySQL，了解MyISAM与InnoDB）
  • 使用
    • 创建DB文档
  • 列定义（选择正确的数据类型）
  • 要标准化的模型数据
  • 参照完整性：主键（自然或代理）;复合键;外键

这引出了我的主要问题，我怎么知道数据库是否足够合适？

3 个答案:

答案 0 :(得分：3)

当你列出为了从创意到工作系统需要回答的一般性问题时，我会建议将它们组织成

非常重要。

1）逻辑设计（获得一个代表您试图建模的问题空间的干净模型）

2）物理设计（RDBMS和存储引擎，确切的数据类型，其他实际和性能相关的决策）

你在两者之间混合太多了。当您获得一个干净的逻辑模型并知道您正在建模的实体之间的关系时，物理建模将不会很难。

修改 有许多书籍涉及逻辑数据设计的步骤，但通常你会尝试：

  1. 定义用例和业务需求（事情相当柔和，检查矛盾的要求;这样做是对那些了解业务流程的人进行访谈，这可能会退化为与自己讨论）
  2. 获取系统中使用的所有属性和实体的列表并定义它们（数据字典）
  3. 确定属性的域（后来在物理层可以作为数据类型完成，检查约束或通过引用'helper'表，但不要担心这一点，只需确保定义域孔）
  4. 绘制定义关系的ER / UML图 - 根据主键，外键和所有其他属性定义表（这次是为了完整性）;这个步骤可以使用CAM完成，体面的图表工具将从图表中吐出CREATE DATABASE脚本
  5. 检查模型以搜索非规范化数据（应该已经规范化，但是当将问题空间转换为逻辑模型时，可能会出错并发现您有冗余或其他异常）

    6. 当您考虑完成某些任务的不同方法时，其中一些步骤需要来回走动。例如，包含新属性可能会让您去分析新的用例。或者发现矛盾的要求可能会导致发现一个全新的实体。或者发现冗余可能会导致您发现存在的无证过程（并证明，或者更确切地说，通过重新定义看似重复的属性来解释经过验证的冗余）。等...

答案 1 :(得分：2)

  1. 在定义列之前对数据建模并对其进行规范化。即使在选择数据库和表格类型之前，这也是您的首要任务，因为它可以让您清楚地了解您正在建模的任务。

  2. 根据需要选择数据库引擎（使用MySQL，知道MyISAM与InnoDB） 权衡是“查询表现”v“交易”。在大多数情况下，innoDB的性能足够好，交易的好处超过了任何不利因素。

  3. MySQL网站上提供了创建表文档。

    4. 正如Unreason所说：“当你得到一个干净的逻辑模型并知道你正在建模的实体之间的关系时，物理建模就不会很难了。”

    成功可以通过各种方式衡量。口袋里的钱，低价硬件上的良好表现。用户的很多快乐评论......比如Stackoverflow：）

答案 2 :(得分：2)

1.选择RDBMS主要是偏好问题。你似乎已经倾向于MySQL了。这没关系，因为MySQL很便宜且很受欢迎。但是，您没有可以同时进行事务和全文搜索的引擎（在MyISAM和InnoDB之间）。 Fulltext Search with InnoDB

2. （和4） MyISAM vs InnoDB and datatypes

  • MyISAM for：全文搜索和表级锁定
  • InnoDB for：事务，FK和行级锁定（但没有全文搜索）
  • 此外，由于行级锁定与表级锁定，InnoDB可能会在大量行中表现更好

3. CREATE TABLE？我更喜欢使用数据库IDE，如Toad for MySQL

5. （和6） Review of DB normalization/PKs/FKs （您需要将InnoDB用于FK。）

7. 你忘了索引！数据库中非常重要的因素。

是如果您有上述要求，MySQL非常适合。

然而，正如我所说，使用MySQL / MyISAM / InnoDB，您没有可以执行全文搜索 AND 事务/ FK的引擎。一个简单的选择是拥有需要全文搜索功能的InnoDB表的第二个副本（在MyISAM中）。您可以这样做，因为您可以在同一个数据库中混合使用2个引擎。或者，您甚至可能不需要全文搜索，因为LIKE足以满足您的应用程序。

另一方面，使用SQL Server，您可以在一个引擎中拥有所有功能，包括全文，事务和FK。

另一种选择是使用单独的技术进行索引全文搜索。有一个MySQL插件：

示例：

相关问题
最新问题