星型模式命名约定
在星型模式中，将表名称作为维度或事实表前缀是否是常见做法？列名以表名作为前缀也是常见的做法吗？
在我的普通 OLTP 数据库中，我不会这样做，但我在星型模式中看到了此类命名的示例。
数据仓库模式与 OLTP 模式采用不同的命名标准是否有意义？
谢谢德怀特
Is it common practice in a star schema to prefix table names as a dimension or fact table? Is it also common practice to have column names prefixed with the table name?
In my normal OLTP databases, I don't do this, but I'm seeing examples of this type of naming in star schemas.
Does it make sense to have a different set of naming standards for data warehouse schemas vs OLTP schemas?
Thanks Dwight
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
表名称：
等）
聚合表
组织、部门和部门日级
列名：
仓库与 OLTP 命名：
Table Names:
etc)
aggregate table
the org, sev & day level
Column Names:
Warehouse vs OLTP Naming:
tablename_column 名称约定用于确保数据库中的所有字段都是唯一的，尽管它有点过分，但可以在存在唯一命名的标准/要求（某些客户 IT 部门要求）时使用。
它消除了任何歧义关于名称的来源。
我宁愿完全不使用前缀来命名表（假设这不会违反公司的本地标准），因为虽然今天它可能是一个表，但明天它可能会被重新实现为视图或分区视图，但会公开相同的架构，然后我将不得不接受前缀不正确的对象或更新每个人对新名称的引用/创建同义词。
虽然保持一致性往往是赢家，但如果每个 DBA/Dev 都实现自己的版本，那就会很混乱，所以我倾向于找到公司标准并应用它们。
The tablename_column name convention is used to ensure that all fields within a database are unique, although it is somewhat excessive it can be used for when there is a standard / requirement for unique naming (Which some client IT departments demand.)
It removes any ambiguity over where Name would come from.
I prefer not to name tables with a prefex at all (assuming that does not break the local standards of a company), since whilst it might be a table today, it could be re-implemented as a view or partitioned view tomorrow but expose the same schema, and I would then have to accept objects prefixed incorrectly or update everyones reference to the new name / create a synonym.
Having consistency though tends to be the winner, if every DBA / Dev implemented their own version it would be chaos, so I would tend to find the company standards and apply them.
在 DW 中，使用“长名称”命名列是很常见的，因为这些列最终会作为报表（查询结果）中的列标题，并且应该对业务用户友好。因此，通常使用
Product，而不是同时显示为“Name”（除非使用别名）的和Product.Name和Customer.Name。 ProductNameCustomer.CustomerName因此，一旦星号通过联接展平，它们就会在报告（查询）的顶行中显示为“ProductName”和“CustomerName”。如果数据库允许的话，经常使用下划线代替驼峰式大小写和空格。当表在模式中的作用可能不明显时，建议在大型数据仓库中使用前缀 dim 和fact；我其实很喜欢他们。It is common in DWs to name columns with "long names" because those columns end up as column headers in reports (query results) and are supposed to be business-user friendly. So instead of having
Product.NameandCustomer.Namewhich would both show up as "Name" (unless alias is used) it is common to useProduct.ProductNameandCustomer.CustomerNameso they show up as "ProductName" and "CustomerName" in top row of a report (query) once the star is flattened via joins. Underscores are frequently used instead of camel-case and blanks, if allowed by the DB. Prefixes dim and fact are recommended in large DWs when table's role in the schema may not be obvious; I actually like them.对于Oracle Business Intelligence Repository，优先使用后缀。
Ken，我喜欢您的 [类型] [主题] [名称] 约定，其中类型为“dim”或“fact”（或聚合的“facts”） 问题在于，在 Oracle 业务智能信息库中创建星型模式模型时，最佳实践建议我们应该为维度和事实表创建别名，并为维度和事实表添加 DIM_（或 dim）和 FACT（或fact_）前缀。
为了避免别名维度和事实表读取dim_dim[表名]或fact_fact_fact_[表名]，最好用_DM（或_dm）后缀命名维度表，用_FT（或_ft）命名事实表） 后缀。
with Oracle Business Intelligence Repository there is a preference towards the use of suffixes.
Ken, I like your [type] [subject] [name] convention, where type is 'dim' or 'fact' (or 'facts' for aggregates) The problem is that when creating the Star schema model in the Oracle Business Intelligence Repository, best practices suggest that we should create alias names for the dimension and fact tables with a DIM_ (or dim), and FACT (or fact_) prefixes for the dimension and fact tables.
In order to avoid having alias dimension and fact tables to read dim_dim[table name] or fact_fact_fact_[table_name), it is preferred to name the dimension tables with a _DM (or _dm) suffix, and the fact tables with a _FT (or _ft) suffix.