设计一个数据库来包含数据库(数据库模型)

发布于 2024-09-30 07:59:29 字数 3327 浏览 0 评论 0原文

我正在开发一个在线数据库建模器,用户可以在其中:

  • 创建新的数据库模式
  • 保存模式 共享模式
  • 修改
  • 模式
  • 分叉模式
  • 对模式进行评论

功能包括:

  • JS 可拖动 UI
  • “实时”ajax 编辑

我想最初支持 MSSql、MySQL 、Postgres 和 SQLite。我想在 Postgres 中创建这个数据库。我对 Postgres 的经验很少,主要是与 MySQL 打交道。

以下是我到目前为止所得出的内容:

引擎

id           int( pk )
name         varchar(40)

引擎的

(
    {"id":1,"name":"postgres"}, 
    {"id":2, "name":"mysql"}
)

示例数据:

数据库

id           int ( pk )
name         varchar(100)
slug         varchar(40)
user_id      int
description  text
engine       int ( fk to engines.id )
fork_id      int ( keep track of forks )
parent_id    int ( this is for revisions )
comment_id   int ( fk to comments.id )
created      timestamptz(6)
modified     timestamptz(6)

的示例数据数据库:

(
    {
      "id":1,"name":"my first db",
      "slug":"my-first-db", 
      "user_id":3, 
      "description":"This is my first database.", 
      "engine":1,
      "created":"2009-09-01 22:22:10",
      "modified":"2009-09-01 22:22:10",
      "comments":3
     }
)


id           int ( pk )
database_id  int ( fk to databases.id )
name         varchar(40)
x_position   int // this is the X position from the top left of the container
y_position   int // this is the Y position from the top left of the container

表的示例数据:

(
    {"id":1,"name":"customers", "database_id":1, "x_position":1, "y_position":2 }
)


字段

id             int ( pk )
table_id       int ( fk to tables.id )
name           varchar(40)
type           int ( fk to types.id )
default        varchar ( 100 )
size           int
autoincrement  tinyint(1)
null           tinyint(1)

字段的示例数据:

(
    {"id":1,"name":"id", "type":2, "table_id":1, "autoincrement":1, "null":1 }
)


>

外键

id                 int ( pk )
origin_field_id    int ( fk to fields.id )
remote_field_id    int ( fk to fields.id )

外键示例数据:

(
    {"id":1,"origin_field_id":2, "remote_field_id":3 }
)


类型

id                 int ( pk )
name               varchar(40)

外键示例数据:

(
    {"id":1,"name":"BLOB" }
)


*types_engines(映射表)*

id                 int ( pk )
type_id            int
engine_id          int

外键的示例数据:

(
    {"id":1,"name":"BLOB" }
)


由于我是一个相对新手的 SQLer,如果有人能够指出我所犯的关键设计缺陷并指出一些事情,我将不胜感激我没有想到也没有预见到这可能是至关重要的。以下是我需要解决的问题。

  • 我的数据库表有一个 fork_idparent_id 。除了保留分叉的修订之外,我还想跟踪数据库是否从其他数据库分叉。我需要这两个才能做到这一点吗?
  • 我对引擎、类型和 types_engines 进行建模的方式是否足够?由于不同的数据库有不同的字段类型,我认为这将是处理该问题的理想方法。
  • 我的总体设计“好”吗?或者您可以发现标准化方面的改进吗?

我意识到我不支持更多高级功能,例如视图/触发器,但我认为这因其简单的性质而很有用。

I'm working on an online database modeler in which users can:

  • create new db schemas
  • save schemas
  • share schemas
  • have revisions of schemas
  • fork schemas
  • comment on schemas

features include:

  • JS draggable UI
  • "live" ajax editing

I want to initially support MSSql, MySQL, Postgres, and SQLite. I want to create this database in Postgres. I have little Postgres experience, I have mostly dealt with MySQL.

Here's what I have come up so far:

engines

id           int( pk )
name         varchar(40)

sample data for engines:

(
    {"id":1,"name":"postgres"}, 
    {"id":2, "name":"mysql"}
)

databases

id           int ( pk )
name         varchar(100)
slug         varchar(40)
user_id      int
description  text
engine       int ( fk to engines.id )
fork_id      int ( keep track of forks )
parent_id    int ( this is for revisions )
comment_id   int ( fk to comments.id )
created      timestamptz(6)
modified     timestamptz(6)

sample data for databases:

(
    {
      "id":1,"name":"my first db",
      "slug":"my-first-db", 
      "user_id":3, 
      "description":"This is my first database.", 
      "engine":1,
      "created":"2009-09-01 22:22:10",
      "modified":"2009-09-01 22:22:10",
      "comments":3
     }
)

tables

id           int ( pk )
database_id  int ( fk to databases.id )
name         varchar(40)
x_position   int // this is the X position from the top left of the container
y_position   int // this is the Y position from the top left of the container

sample data for tables:

(
    {"id":1,"name":"customers", "database_id":1, "x_position":1, "y_position":2 }
)

fields

id             int ( pk )
table_id       int ( fk to tables.id )
name           varchar(40)
type           int ( fk to types.id )
default        varchar ( 100 )
size           int
autoincrement  tinyint(1)
null           tinyint(1)

sample data for fields:

(
    {"id":1,"name":"id", "type":2, "table_id":1, "autoincrement":1, "null":1 }
)

foreign keys

id                 int ( pk )
origin_field_id    int ( fk to fields.id )
remote_field_id    int ( fk to fields.id )

sample data for foreign keys:

(
    {"id":1,"origin_field_id":2, "remote_field_id":3 }
)

types

id                 int ( pk )
name               varchar(40)

sample data for foreign keys:

(
    {"id":1,"name":"BLOB" }
)

*types_engines ( mapping table )*

id                 int ( pk )
type_id            int
engine_id          int

sample data for foreign keys:

(
    {"id":1,"name":"BLOB" }
)

Since I'm a relatively novice SQLer, I would appreciate if anyone can point out critical design flaws I have made and point out things I have not thought about and have not forseen that may be critical. Here are things I need addressed.

  • I have a fork_id and parent_id for my databases table. I would like to track whether databases were forked from other ones, in addition to keeping revisions of the forks. Do I need both of these in order to do that?
  • Is the way I have modeled the engines, types and types_engines sufficient? Since different databases have different field types, I thought this would be an ideal way of handling that.
  • Is my general design "good"? Or are there normalization improvements you can spot?

I realize that there are much more advanced features I'm not supporting such as views/triggers, but I think this will be useful in its simple nature.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

生来就爱笑 2024-10-07 07:59:29

如果您希望开发人员(创建数据库)能够使用 SQL 的所有功能和设施,这是行不通的。你的做法完全错误。你已经做了相当多的工作,设计表格等等,这是必须承认的;但这一切都是不必要的,但这种投资可能会阻碍你放弃它。当然,如果您实现了该结构,则必须有人(a)管理它并(b)维护它。

只要您拥有 ANSI SQL 平台,这些为开发人员提供的设施就已经经过深思熟虑、完整地提供,并且符合已发布的标准(而不是您或我可能认为的供应、控制和测试、共享的好方法)。对象)。请不要重新发明轮子。

  1. 为了自由自在、不受限制的学习领域;这是您的大部分要求:

    • 在服务器中,授予开发者Create_Database权限。
    • 他们可以按照自己的意愿管理自己的数据库、共享数据库等。
  2. 在测试任何共享对象是否可以一起工作之前,需要一个稍微受限的(比自由和简单的)环境。这是一个单一的共享数据库,由您创建和管理(或者,只有一个开发人员获得 DBA 称号)。

    • 创建用户(每个开发者一个)
    • 授予每个用户Create_Table(规则、过程等)权限

    • 他们可以按照自己的意愿管理自己的对象、共享它们等。

    • 每个对象所有者负责构建对象、共享它们,并在其所有者区域中测试它们。在开始开发正式对象之前,这仍然不是与正式测试相关的单一共享区域

    • 用于实际测试的单个共享区域是 DBO

    • 作为 DBA,您只需管理 DBO 对象

    • 没有人是 DBO
    • 当开发人员准备将其私有对象升级为正式共享对象时,他们会通知您
    • 您只需复制其私有对象的 DDL,并将其作为 DBO 执行即可

。管理所需的所有表格等均已实施。它是 SQL 目录。

当然,有许多开发人员和 DBA 工具,只需单击几下即可完成上述任务。

If you want the developers (who create databases) to be able to use all the features and facilities of SQL, that will not work. You are going about it entirely the wrong way. You have done a fair amount of work, designing tables, and so forth, which must be acknowledged; but all that is unnecessary, but that investment may hinder you from giving it up. of course, if you implemented that structure, someone would have to (a) administer it and (b) maintain it.

As long as you have an ANSI SQL platform, those facilities for developers are already supplied, thoughtfully, completely, and to a published standard (as opposed to what you or I may think is a good method of supplyin, controlling, and testing, shared objects). please do not re-invent the wheel.

  1. For the free and easy, unrestricted, learning area; which is most of your requirement:

    • In the server, Grant developers Create_Database permission.
    • They can administer their own databases, share them, etc, to their hearts desire.
      .
  2. Before testing that any shared objects will work together, a slightly more constrained (than the free and easy) environment is required. This is a single shared database, one, which you create and administer (or else, one, and only one, developer gets the DBA designation).

    • Create Users (one per developer)
    • Grant each user Create_Table (Rule, Proc, etc) permission

    • They can administer their own objects, share them, etc, to their hearts desire.

    • Each object owner is responsible for building objects, and sharing them, and testing them in their Owner area. This is still not the single shared area that is relevant to formal testing before development of formal objects is commenced

    • That single shared area, for real testing, is DBO

    • As DBA, you only need to manage DBO objects

    • no one else is DBO
    • When a developer is ready to promote their private object to a formally shared object, they notify you
    • you simply copy the DDL of their private object, and execute it as DBO

That's all. All the tables, etc that are required for administration, is already implemented. It is the SQL catalogue.

There are of course, many developer and DBA tools, which allow the tasks above to be done with a few clicks.

把时间冻结 2024-10-07 07:59:29

查找元数据管理工具和/或 ERWin 或其他数据库设计工具

look up metadata management tools and/or ERWin or other database design tools

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文