有限元分析时划分网格的标准是啥？

Posted 2023-04-25

有限元分析时划分网格的标准是单元属性（包括实常数）、几何模型的定义网格属性。

定义网格的属性主要是定义单元的形状、大小。单元大小基本上在线段上定义，可以用线段数目或长度大小来划分，可以在线段建立后立刻声明，或整个实体模型完成后逐一声明。采用Bottom-Up方式建立模型时，采用线段建立后立刻声明比较方便且不易出错。例如声明线段数目和大小后，复制对象时其属性将会一起复制，完成上述操作后便可进行网格化命令。

网格化过程也可以逐步进行，即实体模型对象完成到某个阶段就进行网格话，如所得结果满意，则继续建立其他对象并网格化。

 网格的划分可以分为自由网格(free meshing)、映射网格(mapped
meshing)和扫略网格(sweep meshing)等。

参考技术A 哈哈,这简单!CAE软件|CAE培训|有限元分析|广州工程仿|真科技有限公司
广州工程仿真科技有限公司,是专业从事大型通用有限元软件销售与培训、有限元分析、工程仿真分析、结构设计、优化与研发、设备及零部件研发仿真的高科技公司。 参考技术B 应该是根据你自己计算的精度确定，要求结果精度高，划分就密一些，但是计算起来会很慢，反之，则划分得疏一些，计算起来很会快，因为网格少 参考技术C altair的hypermesh和msc的patran都不错。 ...有限元分析是对于结构力学分析...如果想做高级的网格话建议学一下ICEM，但是需要一些拓扑几何的知识。希望我的...

您最有用的数据库标准是啥？

【中文标题】您最有用的数据库标准是啥？

【英文标题】：What are some of your most useful database standards?您最有用的数据库标准是什么？

【发布时间】：2010-11-01 20:22:31

【问题描述】：

我有一些想法，一些是我随着时间积累的，但我真的很想知道是什么让你在建模数据库时顺利进行：

表名匹配主键名和描述键 架构按功能区域划分 尽可能避免使用复合主键（使用唯一约束） Camel Case 表名和字段名 不要在表前加上 tbl_，或在过程前加上 SP_（没有匈牙利符号） OLTP 数据库应至少在 BCNF / 4NF 中

【问题讨论】：

“尽可能避免复合主键”——为了避免它们，你会使用多长？我，不多。还有“使用唯一索引”——您的意思是“唯一约束”（提示：并非所有 SQL 产品都使用索引）还是您有特定的产品？

由于人们对我的回答投了反对票，所以我很快就会删除它，我会把它放在评论中。标准化是您可以采用的最佳标准之一。

@Tapoi：为什么不做 5 号？我并不是说这是错误的，我只是想知道 我们公司的隐藏方法

根据我的经验，经常使用复合主键会导致您进入四个层次，两个表之间有一个 8 键连接。除非您使用代码生成器，否则针对此类表编写 SQL 是很乏味的。我建议使用独特的约束。

标准的好处在于有很多选择！

【参考方案1】：

使用相同前缀命名类似的目标存储过程，例如，如果您有 3 个用于 Person 的存储过程。这样，人员的所有内容都集中在一个地方，您可以轻松找到它们，而无需查看所有 proc 来找到它们。 人物更新 人员删除 PersonCreate 当您有一组包含相关数据的表时，对表执行类似的操作。例如： InvoiceHeaders 发票行 InvoiceLineDetails 如果您可以选择数据库中的模式，请使用它们。更好看： Invoice.Header Invoice.Line.Items Invoice.Line.Item.Details Person.Update Person.Delete Person.Create 除非没有其他合理的方法可以实现该目标，否则不要使用触发器。 给字段名称一个有意义的前缀，这样您就可以知道它们来自哪个表，而无需别人解释。这样，当您看到引用的字段名称时，您可以轻松判断它来自哪个表。 对包含类似数据的字段使用一致的数据类型，即不要将电话号码作为数字存储在一个表中，而将 varchar 存储在另一个表中。事实上，不要将它存储为数字，如果我遇到一个负数的电话号码，我会很生气。 不要在表格/字段名称中使用空格或其他晦涩的字符。它们应该完全是字母数字 - 或者如果我有我的 druthers，除了下划线之外完全是字母。我目前正在开发一个继承系统，其中表和字段名称包含空格、问号和感叹号。让我每天都想杀死设计师！ 不要将语法关键字用作对象名称，这会导致尝试从中检索数据时头疼。我讨厌必须将对象名称包装为 [index]，这是两个不必要的字符，我不需要输入该死的你！

【讨论】：

@balabaster：我也这样做。有助于保持井井有条。通常情况下，您有多个搜索 PersonGetByPersonId、PersonGetByName、PersonGetByOderId、PersonGetByCity.. 使用实体名称为代码添加前缀使其非常紧凑。

@balabaster：表名和列名中的问号和感叹号？我好多年没见过了。我对你有感觉，伙计！

+1 打开数据库查看 100 usp_Insert...

为什么对触发器有负面评论？？

@oo 有很多原因：调试起来很麻烦，会引起不必要的混乱，除非您知道它们在那里和/或去寻找它们，否则它们会引起副作用这可能是无法解释的。因此，我只使用它们打算用于的情况，以防止可能给未来的开发人员/DBA 造成混淆的现象。并不是我特别不喜欢触发器，我只是知道会在我之后进来的开发人员，我想让他们的生活尽可能简单。

【参考方案2】：

我还没有看到提到的一件事：

永远不要使用数据库关键字作为对象名称。您不想每次使用它们时都必须对其进行限定

如果您在创建时拼写错误，请在发现后立即修复。不必花费数年时间记住在此表中 UserName 确实是 Usernmae。当针对它编写的代码不多时，它更容易修复。

永远不要使用隐含连接（逗号语法），始终指定连接。

【讨论】：

就像我们架构中的Branches.barnchID...我已经习惯了，但一开始让我很头疼。该架构被两种完全不同的产品使用，因此重命名它并不是一个真正的选择。但我同意你的看法。尽快修复拼写错误！

我认为我们的一张表中仍然有一个“care_hire_driver_id”主键......几年后：o

+1 表示隐含连接，我已经厌倦了修复这样的查询。

老实说，我发现“隐式连接”更加简单易用。您可以立即看到您正在选择哪些表格，因为它们彼此相邻列出，例如“从表 1，表 2”。只要您在 where 子句中首先指定连接字段，就没有问题，例如"WHERE table1.id=table2.table1id AND ..."

哦，别忘了，与您的命名系统不同的表/字段名称 - 例如“用户”表的复数但“消息”表的单数 - 也算作拼写错误，应该尽快修复。

【参考方案3】：

将每个人的意见放在一个列表中。

命名标准

模式按功能区域（产品、订单、运输）命名 没有匈牙利表示法：对象名称中没有类型名称（没有 strFirstName） 不要将已注册的关键字用于对象名称 对象名称中不能有空格或任何特殊字符（字母数字 + 下划线是唯一允许的） 以自然的方式命名对象（FirstName 而不是 NameFirst） 表名称应与主键名称和描述字段匹配（SalesType – SalesTypeId、SalesTypeDescription） 不要以 tbl_ 或 sp_ 作为前缀 对象名称的名称代码（CustomerSearch、CustomerGetBalance） CamelCase 数据库对象名称 列名应该是单数 表名可以是复数 为所有约束提供企业名称 (MustEnterFirstName)

数据类型

跨表使用相同的变量类型（邮政编码 - 一个表中的数字和另一个表中的 varchar 不是一个好主意） 使用 nNVarChar 获取客户信息（姓名、地址）等。您永远不知道什么时候可以去跨国公司

在代码中

关键字总是大写 永远不要使用隐含连接（逗号语法） - 始终使用显式 INNER JOIN / OUTER JOIN 每行一个 JOIN 每行一个 WHERE 子句 无循环 - 替换为基于集合的逻辑 为别名使用短形式的表名，而不是 A、B、C 除非没有追索权，否则避免触发 避免像瘟疫一样的游标（阅读http://www.sqlservercentral.com/articles/T-SQL/66097/）

文档

创建数据库图表 创建数据字典

规范化和参照完整性

尽可能使用单列主键。在需要时使用唯一约束。 将始终强制执行参照完整性 避免删除级联 OLTP 必须至少为 4NF 将每个一对多关系评估为潜在的多对多关系 非用户生成的主键 构建基于插入而不是基于更新的模型 PK 到 FK 必须同名（Employee.EmployeeId 与 EmployeeSalary.EmployeeId 是同一个字段） 除非存在双重联接（Person.PersonId 联接到 PersonRelation.PersonId_Parent 和 PersonRelation.PersonId_Child）

维护：运行定期脚本以查找

没有表的架构 孤立记录 没有主键的表 没有索引的表 非确定性 UDF 备份、备份、备份

做个好人

保持一致 立即修复错误 阅读 Joe Celko 的 SQL 编程风格 (ISBN 978-0120887972)

【参考方案4】：

我对 Oracle 的标准是：

关键字总是大写； 数据库对象名称总是小写； 下划线将替换空格（即不会有任何常见的驼峰式大小写约定，例如 SQL Server）； 主键几乎总是被命名为“id”； 将强制执行参照完整性； 整数值（包括表 ID）通常始终为 NUMBER(19,0)。这样做的原因是这将适合 64 位有符号整数，因此允许使用 Java long 类型而不是更笨拙的 BigInteger； 尽管将“_number”附加到某些列名时用词不当，但此类列的类型将是 VARCHAR2 而不是数字类型。数字类型是为您进行算术运算的主键和列保留的； 我总是使用技术主键；和 每个表都有自己的密钥生成顺序。该序列的名称将是 _seq。

对于 SQL Server，唯一的修改是对数据库对象名称使用驼峰式大小写（即 PartyName 而不是 party_name）。

查询倾向于多行编写，每行一个子句或条件：

SELECT field1, field2, field2
FROM tablename t1
JOIN tablename2 t2 ON t1.id = t2.tablename_id
WHERE t1.field1 = 'blah'
AND t2.field2 = 'foo'

如果 SELECT 子句足够长，我会将其拆分为每行一个字段。

【讨论】：

几乎只与 Oracle 合作，我必须在每一点上都同意你的看法。但是，我确实发现 CamelCase 的使用对手指更友好，而不是输入很多下划线。我们有一个第三方系统，其架构中有大约 200 个表，他们选择根本不使用下划线。例如PROJECTTASKTYPE 而不是 PROJECT_TASK_TYPE，虽然阅读起来有些困难，但我不得不承认输入这样的查询更容易。

我们也将“old_school_names”用于 SQL Server。除此之外，我们的主要区别是我更喜欢使用“tablename_id”而不是“id”作为主键——冗余，但有时很有用；这也意味着大多数时候，表 A 和表 B 之间的链接是在同名列上建立的，例如purchase.purchase_type_id=purchase_type.purchase_type_id。我们还指定表名应该是单数，而不是复数（“purchase”，而不是“purchases”）。

我的架构师说他想在名称不明显的连接表中使用下划线。例如，如果 Customer 和 Product 使用 OrderId 的 PK 加入 Order，我们就设置好了！但是如果 Products 和 Category 连接，并且连接没有业务名称，那么我们会得到 Product_Category 和 Product_Category_Id。 (SQL 服务器)

【参考方案5】：

命名所有约束

【讨论】：

我喜欢为约束赋予有意义的名称的想法。

【参考方案6】：

不要忘记定期备份您的数据库。

【讨论】：

我会更进一步。 每天备份，每周恢复。始终仔细检查您是否可以实际恢复备份，否则您会在困难时期发现您的备份不够好。

【参考方案7】：

不要在字段名称中使用类型名称。年长的人会记得 lpszFieldName 的旧 MS 标准以及随之而来的愚蠢。

使用符合正常语言约定的描述性字段名称。例如“FirstName”而不是“NameFirst”

字段名称中的每个单词都大写

没有下划线

不要使用“索引”等普通关键字

不要在任何对象类型前加上前缀。例如，我们不使用 tblCustomers 或 spCustomersGet。这些不允许良好的排序并提供零值。

使用模式来定义数据库的不同区域。例如sales.Customers 和hr.Employees。这将摆脱人们使用的大多数前缀。

对任何类型的循环都应持怀疑态度。通常有更好的基于集合的方式。

对复杂的连接使用视图。

尽可能避免复杂的连接。拥有一个 CustomerPhoneNumbers 表可能更美观；但老实说，我们真的需要存储多少电话号码？只需将字段添加到客户表。您的数据库查询会更快，也更容易理解。

如果一个表调用字段“EmployeeId”，那么引用它的每个表都应使用该名称。它不需要仅仅因为它在扩展表中就被称为 CustomerServiceRepId。

几乎所有表格都有“s”结尾。比如：Customers、Orders等。毕竟表里有很多记录……

使用分析工具评估您的查询、索引和外键关系。甚至那些可能为您生成的。你可能会感到惊讶。

支持多对多关系的链接表在名称中包含两个链接表。例如，SchoolsGrades。通过表名很容易判断它的作用。

保持一致。如果你从一个约定的路径开始，除非你愿意重构所有以前的工作，否则不要半途而废。这应该会制止任何“如果......不是很好”的想法，这些想法最终会导致混乱和大量返工。

在输入之前三思。你真的需要那个表、字段、存储过程或视图吗？你确定它没有被其他地方覆盖吗？在添加之前获得共识。如果由于某种原因您必须将其取出，请先与您的团队交谈。我一直在 DBA 每天进行重大更改而不考虑开发人员的地方。这不好玩。

【讨论】：

非常不同意#10，大多数时候这是一个非常糟糕的做法，你必须改变表结构来添加一个新的电话类型。您会惊讶于需要为某些人存储多少电话号码。我强烈同意#8。

#10 +1。你不能夸大过度标准化的成本。

@Joe，我会在前面加上一些有意义的信息。 IE、responsibleEmployeeId 或 assistantEmployeeId

@Tapori，我同意#10 可能在某种程度上取决于系统要求。但是，我不认为你的例子是好的。对于通话记录，最好将实际电话号码放在历史记录表中，地址也一样。它应该在 Order 表中。原因是即使有人从您的“电话”或“地址”表中删除了记录，这也可以保持您的历史记录完好无损。重复数据？可能，但您的数据更容易报告，并且这些字段中的数据永远不会改变。

继续：通过将电话号码与实际通话记录保存在同一记录中，您的 UI / 数据层可以使用主客户帐户管理电话号码，而无需考虑损坏的历史记录。地址和订单也是如此。

【参考方案8】：

如果数据库用于特定应用程序，请有一个版本表，以便可以根据代码版本检查数据库版本（以及其他原因）。

【参考方案9】：

我总是尽量不使用字段名称中的类型 - “sFirstName”、“sLastName”或“iEmployeeID”。虽然它们一开始是匹配的，但如果发生变化，它们就会不同步，而且以后更改这些名称是一件非常头疼的事情，因为您还必须更改依赖对象。

Intellisense 和 GUI 工具使找出列是什么类型变得很简单，所以我觉得这没有必要。

【参考方案10】：

WITH 子句确实有助于将查询分解为可管理的部分。

它还确实有助于提高查询执行计划的效率。

【参考方案11】：

确保每个 varchar/nvarchar 选择都是合适的。

确保每个 NULLable 列的选择都是适当的 - 尽可能避免 NULLable 列 - 允许 NULL 应该是合理的位置。

无论您在此处的建议中可能使用什么其他规则，我都会在数据库中创建一个存储过程，该过程可以定期运行以确定您拥有的任何规则或标准的系统运行状况（其中一些是一点点 SQL-Server 特定）：

在由于某种原因无法使用 DBMS 系统的参照完整性的任何情况下查找孤立记录（在我的系统中，我有一个进程表和一个测试表 - 所以我的 system_health SP 会查找没有测试的进程，因为我只有单向的 FK 关系）

查找空架构

查找没有主键的表

查找没有任何索引的表

查找没有文档的数据库对象（我们使用 SQL Server 扩展属性将文档放入数据库中 - 此文档可以像 列一样细化）。

查找特定于系统的问题 - 需要归档的表、不属于正常每月或每日处理的异常、某些带有或不带有默认值的常见列名（例如 CreateDate）。

查找非确定性 UDF

查找 TODO cmets 以确保 DB 中的代码没有未经测试或预发布的代码。

所有这些都可以自动化，让您全面了解系统健康状况。

【参考方案12】：

每个人都以相同的基本格式编写 SQL 查询（视图、存储过程等）。它确实有助于未来的开发/维护工作。

【讨论】：

这不是它的工作原理。你将收购另一家公司，或整合另一家产品，它们的格式将完全不同

:) 假设每家公司有 10 名开发人员。我认为 Lance 的意思是，我们得到 两种 标准样式而不是 20 种（前提是人们不会在途中改变他们的编码样式）。

【参考方案13】：

一致的命名标准。让每个人都在同一个页面上，使用相同的格式（无论是驼峰式大小写、特定前缀等）有助于准确维护系统。

【讨论】：

一致性可以说比任何特定标准都更重要。 （只要它按照我的方式完成，我很高兴：p）

【参考方案14】：

一些喜欢和不喜欢。

我认为前缀在各个方面都很糟糕。我目前在一个以表为前缀的系统上工作，表中的列以 2 个字母的表名首字母缩略词为前缀，我每天至少浪费 30 分钟在这个数据库上工作，因为首字母缩略词不合逻辑。如果您想用前缀表示某些东西，请改用架构所有者。

在项目开始时使用 NVarchar，如果有轻微的暗示表明文本数据需要支持多语言字符。由于缺乏前瞻性计划和思考而升级大型数据库是一种痛苦和浪费时间。

将 where 子句中的每个条件拆分到新行以提高可读性（在而不是在括在括号和标签中的语句中。）我认为这对我来说是重要的标准。

我曾在一家公司工作，其标准是在执行参数或变量声明时，逗号必须始终放在行首。这显然使它更具可读性，但我发现它完全是一场噩梦。

【讨论】：

参数前面的逗号（而不是结尾）很难习惯，但是当你想注释掉某些东西时很方便。无需注释掉该特定行和之前行上的逗号。

我也承认，负责我们外包公司的那个人也是个白痴，他会因为一个逗号不合适而拒绝一个项目。拒绝过程浪费了大家3天的时间，1个逗号。然后他试图向我们推销一个代码生成器，它根据他的法律条文创建存储过程。这就是我讨厌逗号标准的另一个非技术原因！

【参考方案15】：

除了标准化为 3NF 或 BCNF（更多关于 this question 的内容），我发现以下内容很有用：

将表命名为复数名词 将列命名为单数

所以“People”表有一个“PersonID”列。

只要 3NF 或 BCNF 的规则仍然成立，复合键就没有问题。在许多情况下（例如“多对多”情况），这是完全可取的。 避免在列名中重复表名。无论如何，peoplePersonID 最好写成 table.column，并且可读性更强，因此可以自我记录。至少对我而言，People.PersonID 更好。 应

非常小心地使用 ON DELETE CASCADE

。 请记住，NULL 表示以下两种情况之一：未知或不适用。 还请记住，NULL 对联接有有趣的影响，因此请练习您的 LEFT、RIGHT 和 FULL 外联接。

【讨论】：

抱歉，表名的复数名词是我的敌人（我正在使用一个有人认为这是个好主意的数据库...）

更准确一点：我提倡强实体使用复数名词；即，那些行可以在其他表中没有任何依赖关系的表。对于弱实体（关联、子类型等），复数名词不太适合。动词可能更好。所有这些都是为了帮助改进自我文档并传达设计的意图。您在提到的数据库中看到了什么样的问题？

我想你已经提到了其中一个问题——“people”表有一个“personid”列。至少对于通过将“_id”（或“ID”）附加到表名来命名主键的我们来说，这已经被破坏了。同样在查询中，谓词作用于表中的一行，而不是表本身。因此，要使查询自然地阅读，您必须将所有表重新命名为单数名称，以避免使用“people.first_name”而不是（恕我直言）“person.first_name”。这再次符合我的标准之一：仅在需要时在查询中使用表别名。

此外，表不仅仅是行的物理分组——它们是一种类型的定义，类似于开发世界中的类。在这种情况下，通常单独命名类和类型（例如“typedef struct person”或“class Person”）。

@araqnid - 有趣的点。回复：主键 - 我同意，如果您的约定是将 PK 命名为表名 + ID，那么复数名词方案就被破坏了。但我不喜欢那个大会。一方面，带有复合键的表也会破坏它。

【参考方案16】：

其他一些（虽然很小）的cmets要扔到墙上......

SQL Server 数据库架构可用于组织表和存储过程以及控制安全性。

每个事务表都应始终跟踪创建记录的人员和时间，并在单独的列中更新记录。我见过简单地使用“更新日期”的实现，这可能会导致未来的审计挑战。

对具有离线/同步要求的项目的所有行使用 GUID 作为行标识符。

【参考方案17】：

良好的数据库设计和规范化。

【讨论】：

这不是一个标准。一个标准会说“数据库必须规范化到最低 3NF”或类似的东西。

这就像说“程序员必须写好代码”并称其为标准。

如果你不想标准化你的数据库那太糟糕了。无论如何，这将是我的标准。

这些是我的标准。如果你不喜欢它们，我有不同的。

【参考方案18】：

表格以单数、小写、无下划线、无前缀命名 字段也是小写，没有下划线，没有前缀 以“st_”为前缀的存储过程（排序很好） 被视为表格的视图没有前缀 为特殊报告等创建的视图具有“v”前缀 为性能而创建的索引视图具有“ixv”前缀 所有索引都有专门的名称（没有自动命名） 对于代理键，相比 int IDENTITY，强烈推荐 uniqueidentifier（按顺序递增） 不要人为地将 VARCHAR/NVARCHAR 字段限制为 100 或 255。给他们喘息的空间。这不是 1980 年代，字段没有存储到最大长度。 3NF 最低标准 更喜欢连接表而不是列级外键：随着系统随着时间的推移，许多 1:m 假设受到挑战。 始终使用代理键而不是自然键作为主键。 所有关于“自然”密钥（SSN、用户名、电话号码、内部代码等）的假设最终都会受到挑战。

【讨论】：

@richardtallent：不知道你在这里的意思是“更喜欢加入表而不是列级外键”。你能详细说明一下吗？

@Tapori - 假设规格低估了现实的模糊性。如果有人说 1:m 关系是合适的，请将其实现为连接表（从而最终允许 m:m）。 （显然，只有在性能正常的情况下。） 示例：今天：“保修数据库中的每个单独的产品都应该分配给一个客户。”因此，您在 Product 表中实现为外键：Product.CustomerID --> Customer.ID。几个月后：“哎呀，保修是可以转让的。我们不想覆盖 Product.CustomerID 或伪造 Product.SerialNumber。让它多：多。”

【参考方案19】：

表格格式的 SQL。

select a.field1, b.field2
from       any_table   a
inner join blah        b on b.a_id       = a.a_id
inner join yet_another y on y.longer_key = b.b_id
where a.field_3         > 7
and   b.long_field_name < 2;

部分原因是使用统一长的别名（在示例中，这里的 a、b 和 y 的长度都是 1）。

通过这种格式，我可以更快地回答常见问题，例如“什么表被 'a' 别名了？”和“哪些字段将表 T 连接到查询中？”该结构不需要很长时间来应用或更新，我发现它节省了很多时间。我们花在阅读代码上的时间多于编写代码。

【讨论】：

@carl：我的导师在我脑海中敲定了 a、b、c 的前缀，bad、BAD。所以我使用相同的短名称作为前缀。

直到您进入制表符与空格的辩论？ :)

@Tapori：这个人为的例子没有真实姓名和真实缩写的基础。可能我最常用的别名是两个字符的缩写，在简单查询的简短上下文中，这就足够了。它让我可以使用长的、易于理解的实际表名。

【参考方案20】：

记录一切； wiki 类型的文档易于设置，并且软件是免费的。

确保您首先了解界面，然后再设计数据库。大多数时候，最好知道您将要使用的数据如何工作，然后设计数据库。大多数糟糕的数据库设计发生在事情发展不提前的时候。

然后定义您要使用的数据库标准和版本。定义代码元素（视图、函数等）、数据库命名的标准；列、表的命名约定；列的类型约定；编码模板。

花时间考虑如何为字段定义具有标准数据库类型的类型或预先确定类型是一件好事。

作为文档的一部分，包括应用程序的注意事项和注意事项列表，其中包括您喜欢的功能光标、触发器。

定期查看。

【讨论】：

-1 我从未见过真正的公司记录任何内容，更不用说记录所有内容了。我们通过了 ISO 9001 认证。而且我们不会记录任何重要的内容。

可能是文化问题；在我现在的公司，我们在开发开始时编写了一本圣经，其中涵盖了数据库和开发软件标准。上一家公司的开发标准就像您的 ISO 文件；我更喜欢文档。

【参考方案21】：

13- 评估您的查询

确实如此。有时你得不到你想要的。

对我来说，用它们的确切内容命名表和字段总是有用的，（对我们来说）用清晰的西班牙语和大写驼峰式命名，没有空格：

用户名：NombreUsuario

名字：ApellidoPaterno

第二姓：ApellidoMaterno

等等等等

【参考方案22】：

将“数据库”表示为“SQL 产品”，我的回答是，“太多了，不胜枚举。你可以写一本关于这个主题的整本书。”令人高兴的是，有人拥有。

我们使用 Joe Celko 的 SQL 编程风格 (ISBN 978-0120887972)：“这本书是启发式和规则、提示和技巧的集合，可帮助您提高 SQL 编程风格和熟练程度，并用于格式化和编写可移植的、可读、可维护的 SQL 代码。”

这种方法的优点包括：

这家伙比我更了解这种事情（还有其他关于 SQL 启发式的书吗？！）； 工作已经完成，例如我可以将这本书交给团队中的某个人阅读和参考； 如果有人不喜欢我的编码风格，我可以责怪其他人； 我最近通过推荐另一本 Celko 书在 SO 上获得了大量代表 :)

在实践中，我们确实偏离了书中的规定，但令人惊讶的是很少。

【参考方案23】：

在 MS-SQL 中，我一直拥有 dbo 拥有的对象。我在对这些对象的调用前加上 dbo。

很多次我看到我们的开发人员想知道为什么他们不能调用他们无意中拥有的对象。

【参考方案24】：

避免愚蠢的缩写约定，例如积极鼓励诸如 EMP_ID_CONV_FCTR_WTF_LOL_WAK_A_WAK_HU_HU 之类的怪物的综合缩写字典。这条规则的灵感来自我以前见过的一套真实的指导方针。

【参考方案25】：

MVP Aaron Bertrand's "My stored procedure "best practices" checklist"

【参考方案26】：

表名匹配主键名和描述键

在同意这一点多年后，我最近才跳槽，现在每张桌子上都有一个“ID”列。

是的，我知道，在链接表时它是模棱两可的！但是将 ProductID 链接到 ProductID 也是如此，呃，为什么要额外输入？

这个：

SELECT p.Name, o.Quantity FROM Products p, Orders o WHERE o.ProductID = p.ID

比这个稍微好一点：

SELECT p.Name, o.Quantity FROM Products p, Orders o WHERE o.ProductID = p.ProductID

请注意，两者都需要表或别名前缀。但不仅我输入的字数略少（乘以数十个具有长描述性名称的表，并且它在数据密集型应用程序中快速加起来）而且它还可以更容易地知道哪个表是每个连接中的父表，哪个，在一个查询中加入 8-10 个表时，会有很大帮助。

【参考方案27】：

我在这里遵循许多与其他人相同的约定，但我想说一些尚未说的话。

无论您喜欢表的复数名称还是单数名称，都要保持一致。选择其中一个，但不要同时使用。

表中的主键与表同名，后缀为_PK。外键与其对应的主键同名，但后缀为 _FK。比如Product表的主键叫做Product_PK；在 Order 表中，对应的外键是 Product_FK。我从另一个 DBA 朋友那里养成了这个习惯，目前我很喜欢。

每当我执行 INSERT INTO...SELECT 时，我都会为 SELECT 部分中的所有列设置别名，以匹配 INSERT INTO 部分中列的名称，以便更容易维护并查看事情如何匹配。

【参考方案28】：

最重要的标准是：默认没有数据库。我发现太多的开发人员为那些没有数据库的项目（至少现在）生活会容易得多。它只是工具箱中的一个工具，并不是每个问题都是钉子。

不恰当地使用数据库会导致领域模型贫乏、代码可测试性差和不必要的性能问题。

【参考方案29】：

除了#5 之外，我几乎同意您在此处提出的所有内容。我经常为表和存储过程使用前缀，因为我们开发的系统有很多不同的功能区域，所以我倾向于在表和存储过程前加上一个标识符，这将允许它们在 Management Studio 中根据什么区域很好地分组他们属于。

示例：cjso_Users、cjso_Roles，然后你有 routing_Users、routing_Roles。这听起来像是数据复制，但实际上两个不同的用户/角色表用于系统的完全独立的功能（cjso 将用于基于客户的电子商务应用程序，而路由将代表使用路由的员工和分销商系统）。

【参考方案30】：

我喜欢我们的表格命名约定：

People Table
PEO_PersonID
PEO_FirstName 
...

这有助于使较大的查询更具可读性。和连接更有意义：

Select * -- naughty!
From People
Join Orders on PEO_PersonID = ORD_PersonID
--...

我猜不是命名约定是什么，而是命名的一致性。

【讨论】：

从 PEO.PersonID=ORD_PersonID 上的 PEO 加入 ORD 中选择 *。使用别名而不是前缀。

好主意，如果从头开始我会坚决考虑。然而，这是一个长期存在的数据库，不太可能改变它的约定（这是一件好事，一致性总是一个加分项）

Schemas (mssql 2005 +) 会是更好的选择！

我和 ScottE 一起讨论这个问题，我认为 mssql 2005 + 和 oracle 中的模式更有意义。如果您要使用前缀，则使前缀首字母缩写词有意义。