|
|
1
3
我发现的唯一通常适用的解决方案是开发一系列前缀并将它们应用到表中(例如,主要与人力资源相关的表都将启动hr_uu)。我通常将前缀带到应用程序中的其他“对象”(窗体、报表、视图、存储过程)。 这个解决方案还远远不够完美,有点像黑客,但它确实为系统带来了一点秩序。 |
|
|
2
2
Oracle电子商务套件有25000多个表和约33000个视图。我会说这是一个大模式。 |
|
|
3
1
当然,一定要使用命名约定。MySQL数据库设计是我最后使用匈牙利符号的地方之一,但是我的所有表都以“tbl”开头,所有视图都以“v”开头。 此外,我在MySQLWorkbench中构建了多个数据库图表,通常每个域聚合至少一个图表,这有助于我可视化体系结构中的“模块”。 这是一个像SQL Server这样的产品具有很大优势的领域,因为数据库对象可以属于数据库中的多个模式,很像编程中的名称空间。 |
|
|
4
1
好。。。MySQL中没有真正的解决方案。对于某些数据库(例如PostgreSQL),您确实有名称空间,可以这样做。 当然,您可以通过使用多个数据库来模拟名称空间来解决这个问题,但这可能会带来很多问题。 就我个人而言,我只是简单地以您的管理工具能够区分的方式命名所有内容(比如phpmyadmin自动使用下划线对数据库进行分组)。 |
|
|
5
1
在某些数据库中,您可以使用模式,但我认为MySQL中没有。保持相关表在一起的命名约定是最好的选择。我特别要做的一件事是在不同表中命名字段时非常一致,完全相同。如果我的用户表调用了一个用户ID,那么我不想在不同的相关表中将其视为个人ID、用户ID、用户等。同样,在表与表之间使用相同类型的字段时,使用相同的数据类型(如果是字符串数据,则使用大小)。这样就不需要不断地将数据转换为连接。 至于需要多少个表才能成为一个大型数据库,那更多的是一个函数表中有多少条记录,而不是表的数量。许多小型数据库都有数百个表。我几乎从不担心表格的数量,除非我看到有人创建表格,如Financial2009、Financial2010等。 |
|
|
6
1
在一个项目中,一个对我很有效的解决方案是,我们将数据库分成若干块,然后画一个大的ERD(实际上,我们使用了COREL,尽管有许多更高级的工具可用),我们对每个表的框进行颜色编码,以显示每个表中的块,然后在一台大格式打印机上打印出来,这样它就有5英尺高,10英尺高。我们把它挂在我助理办公室的墙上。不是高科技的解决方案,但它非常实用。 我们对一致的命名也非常细致,以回应Hlgem的回答。 回想起来,在每个表名前面加上一个“块名称”的命名约定可能是个好主意,但没有它,我们的进展相当顺利。 大到多大?我不知道,一个非常主观的问题。我通常认为,当我不能一次在脑海中描绘出整个事情时,数据库就很大了。实际上,我猜当你通过几十张桌子的时候。记录的数量非常不相关:一个数据库有两个表,每个表有10亿条记录,这很容易理解;一个数据库有1000个表,每个表有10条记录,这很难理解。 |
|
|
7
0
…但是可以在同一个MySQL实例上运行多个数据库,例如
(注意,尽量避免使用MySQL“use dbname”)。最好在查询中标准化别名。
我认为没有标准的度量标准。我可能会在50岁左右开始困惑。我关注的一个Oracle DBS有1567个(是的,它是规范化的(有点)) |
|
|
blogger13 · 视频租赁店数据库的规范化 1 年前 |
|
|
ì¤ì¤í · 为什么LEFT INNER JOIN被弃用? 1 年前 |
|
|
relatively_random · 确保两个表之间一致的共同参考 1 年前 |
|
|
Grenish Rai · Firestore错误“用户文档不存在” 1 年前 |
|
|
Saijo-Shi · PLpgsql中的更新触发器 2 年前 |
|
Dante · Django::配置不当:池不支持持久连接 2 年前 |
|
YouLocalRUser · 删除重复行,保留第一行 2 年前 |