星型模式命名约定

Dwi*_*t T 7 sql-server star-schema

星型模式中的常见做法是将表作为维度或事实表加前缀吗?将列名称作为表名前缀的常见做法是什么?

在我的普通OLTP数据库中,我没有这样做,但我在星型模式中看到了这种类型的命名示例.

为数据仓库模式和OLTP模式设置不同的命名标准是否有意义?

谢谢德怀特

Ken*_*Far 8

表名:

  • 我喜欢这个惯例:[type] [subject] [name]
  • 其中type为'dim'或'fact'(或聚合的'fact')
  • 其中subject是仓库中的主题区域('comm'为common,'fw'为防火墙,'id'等)
  • 其中name理想地是单个单词名称,或者在聚合表的情况下是维度的缩写
  • 例如:dim_comm_org用于组织维度
  • ex:scan_scan用于扫描事实表
  • 例如:facts_scan_org_sev_daily - 在org,sev和day级别分组的事实扫描汇总表

列名:

  • 不要用整个表名前缀 - 这太长了
  • 为前缀添加一个有意义的部分 - 这在编写或阅读查询时非常有用.

仓库与OLTP命名:

  • 两者非常不同.仓库表和列名称通常以元数据,报告结束,由开发人员和用户读取.与OLTP不同.
  • 我认为表前缀在OLTP中仍然有用 - 但我觉得最好是它对模型的那个子集有意义而不是事实/维度的区别.

  • @pimbrouwers - 假设您有表:fact_security_vuln、dim_comm_org 和 dim_comm_asset。如果您在这些表中的任何一个中都有“名称”列,并在复杂的查询(如 CTE)中使用它们,那么跟踪它的来源很快就会成为一种负担。因此,您可以设置列名称,例如“vuln_*”、“org_*”、“asset_*”,而不是依赖表别名。这些前缀需要简短 - 所以它们可能不是万无一失的限定符。 (2认同)

And*_*rew 3

tablename_column 名称约定用于确保数据库中的所有字段都是唯一的,尽管它有点过分,但可以在存在唯一命名的标准/要求(某些客户 IT 部门要求)时使用。

Product.Name => Product.Product_Name
Part.Name => Part.Part_Name
Run Code Online (Sandbox Code Playgroud)

它消除了名称来源的任何歧义。

我宁愿完全不使用前缀来命名表(假设这不会违反公司的本地标准),因为虽然今天它可能是一个表,但明天它可能会被重新实现为视图或分区视图,但会公开相同的架构,然后我将不得不接受前缀不正确的对象或更新每个人对新名称的引用/创建同义词。

虽然保持一致性往往是赢家,但如果每个 DBA/Dev 都实现自己的版本,那就会很混乱,所以我倾向于找到公司标准并应用它们。