【问题标题】:How to design DB table / schema with ease?如何轻松设计数据库表/模式?
【发布时间】:2010-10-27 11:19:57
【问题描述】:

是否有一种简单的方法可以确定您设计的应用程序中每个表需要哪些字段和索引?

例如,如果它是一个 web 应用程序,它只允许人们创建列表(任意数量的列表,并且用户可以创建“待办事项”列表或“购物”列表),并且用户可以分配其他用户来编辑列表,以及该列表是公开查看还是仅对某些用户可见,如何设计表格以使其非常准确并快速设计?索引呢?

我在大学时这样做了,然后不久前重新审视了这个问题并有了一个方法,但想知道在该领域是否有标准和好的方法来解决这个问题。

【问题讨论】:

  • 这个问题的范围很广。您可能还问过“如何设计数据库?”。
  • 其实,上面那个示例问题,我在一次采访中被问到,预计几分钟后会得到答复。

标签: database database-design schema


【解决方案1】:

数据库设计很难......

与生活中的许多事情一样,这是一系列权衡。您需要决定的第一件事是您将使用什么 DBMS,(MySQL、SQL Server、Oracle、PostgreSQL、“面向对象”数据库之一等。

然后,您需要决定规范化与疯狂数量的 JOIN 以获取您的数据。需要解决诸如“我将在触发器、存储过程、应用程序代码等中实现多少逻辑”之类的问题。

除了最琐碎的数据库之外,没有“Quick'n'Easy”的方式来设计任何东西。

'当然,这只是我的经验。 YMWV。

【讨论】:

  • 为什么“引用”中是“面向对象”? :-)
  • 我唯一有直接经验的“面向对象”数据库是 Intersystems 的 Caché,它是一个并行的 SQL 层、VB 层和对象层,在一个 M(umps) 数据库上,这是一个很好的老式(如 60 年代后期,IIRC)层次结构数据库......当谈到数据库设计中的 Object-ey Idealism 时,这种经历让我心碎。
  • 因为关系数据库不能很好地建模继承。
【解决方案2】:

完全解释数据库设计超出了这个答案的范围

我通常将我的设计分为三个部分(第 1 部分和第 2 部分发生在前面,而第 3 部分通常在项目结束时)
1) 根据关系(父/子/等)创建表
2) 根据内容创建字段(父级具有 x 属性等)
3) 最后根据您从表中选择数据的方式创建索引

【讨论】:

    【解决方案3】:

    还没有听说过解决这个问题的任何正式方法,但有经验法则。所有的名词和业务对象都变成了表格,当然是标准化的。而且我认为这些属性不言自明。我猜?

    至于索引,它只是与数据一起使用。任何连接的列都应该有一个索引(甚至可能是聚集的)。这非常...取决于。但是有模式。但是除了针对连接进行优化之外,许多索引都与数据的使用方式直接相关,这不是凭经验可以提供的。就像你通过 pk 和其他地方的 last_name 查找用户一样,last_name 值得一个索引。

    【讨论】:

      【解决方案4】:

      我认为解决方案是主观的。当我必须设计表时,我会查看代表特定数据模型的 Java 对象并从那里开始。你会发现很多框架(Django、CakePHP、RoR)都有你开发模型,框架会构建相应的表。

      因此,我建议评估您需要哪些功能和数据来存储和开发您的表格。还要查看您可以使用的工具集是否可以根据对象结构为您生成表格。

      【讨论】:

        【解决方案5】:

        我会选择直接(几乎)标准化的设计:

        CREATE TABLE lists (
                            listid serial, 
                            name varchar, 
                            ownerid int references users(userid)
                           )
        
        CREATE TABLE list_items (
                                 listid int references lists(listid), 
                                 value varchar, 
                                 date datetime
                                ) 
        
        CREATE TABLE permissions (
                                  permissionid serial, 
                                  description varchar,
                                 )
        
        CREATE TABLE list_permissions (
                                       listid int references lists(listid),
                                       permissionid int references permissions(permissionid)
                                       userid int references users(userid)
                                      )
        CREATE TABLE users (
                             userid serial,
                             name varchar
                           )
        

        要创建哪些索引取决于实际最常用的查询是什么以及它们的执行情况。例如,如果您在列表和 list_items 上进行大量查询(很可能),如果您将按名称搜索,那么您会希望在 listid 和 name 上建立索引。

        只是一些想法。希望对您有所帮助。

        【讨论】:

          【解决方案6】:

          如果你仍然想看看什么有效,我会尽量不要把自己锁在里面。

          根据您的描述,您需要一个表格来存储用户信息,以及:

          tbl_lists:
              ID_list (primary key)
              UserID (foreign key to list owner)
              ListName
          
          tbl_listItems:
              ID_listItem (primary key)
              ListID (foreign key to list)
              ItemDescription
          
          tbl_permissions:
              ID_permission (primary key)
              ListID
              UserID (foreign key to user you're granting permission to)
              PermissionTypeID (what kind of permission)
          
          tbl_permissionTypes:
              ID_permissionType (primary key)
              Description ("can view", "can edit", etc.)
          

          您在设计时可以更灵活地制作东西,效果就越好。您可以稍后进行优化。

          【讨论】:

            【解决方案7】:

            如果你想让事情变得非常简单并且不太关心规范化。您可以创建一个大表来存储您的 webapp 所基于的主要对象,例如:列表,并让其他较小的支持表链接到大表,例如:tbl_listType、tbl_permission、tbl_list_items。

            然后,当您编写查询时,您几乎可以肯定包括主表,并且您可以链接到其他支持表以获取更详细的详细信息。

            【讨论】:

              猜你喜欢
              • 1970-01-01
              • 2015-11-07
              • 1970-01-01
              • 1970-01-01
              • 1970-01-01
              • 1970-01-01
              • 2010-11-28
              • 1970-01-01
              • 1970-01-01
              相关资源
              最近更新 更多