设计一个数据库来包含数据库(数据库模型)
我正在开发一个在线数据库建模器,用户可以在其中:
- 创建新的数据库模式
- 保存模式 共享模式
- 修改
- 模式
- 分叉模式
- 对模式进行评论
功能包括:
- 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_id
和parent_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
andparent_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 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
如果您希望开发人员(创建数据库)能够使用 SQL 的所有功能和设施,这是行不通的。你的做法完全错误。你已经做了相当多的工作,设计表格等等,这是必须承认的;但这一切都是不必要的,但这种投资可能会阻碍你放弃它。当然,如果您实现了该结构,则必须有人(a)管理它并(b)维护它。
只要您拥有 ANSI SQL 平台,这些为开发人员提供的设施就已经经过深思熟虑、完整地提供,并且符合已发布的标准(而不是您或我可能认为的供应、控制和测试、共享的好方法)。对象)。请不要重新发明轮子。
为了自由自在、不受限制的学习领域;这是您的大部分要求:
。
在测试任何共享对象是否可以一起工作之前,需要一个稍微受限的(比自由和简单的)环境。这是一个单一的共享数据库,由您创建和管理(或者,只有一个开发人员获得 DBA 称号)。
授予每个用户Create_Table(规则、过程等)权限
他们可以按照自己的意愿管理自己的对象、共享它们等。
每个对象所有者负责构建对象、共享它们,并在其所有者区域中测试它们。在开始开发正式对象之前,这仍然不是与正式测试相关的单一共享区域
用于实际测试的单个共享区域是 DBO
作为 DBA,您只需管理 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.
For the free and easy, unrestricted, learning area; which is most of your requirement:
.
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).
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
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.
查找元数据管理工具和/或 ERWin 或其他数据库设计工具
look up metadata management tools and/or ERWin or other database design tools