Questions tagged «best-practices»

最佳实践通常和非正式地被认为是随着时间的推移显示出优于通过其他方式实现的方法和过程。

6
什么时候应该使用唯一约束而不是唯一索引?
当我希望一列具有不同的值时,我可以使用约束 create table t1( id int primary key, code varchar(10) unique NULL ); go 或者我可以使用唯一索引 create table t2( id int primary key, code varchar(10) NULL ); go create unique index I_t2 on t2(code); 具有唯一约束的列似乎是唯一索引的良好候选者。 是否存在使用唯一约束而不使用唯一索引的已知原因?

19
开发人员应该能够查询生产数据库吗?
是否应授予开发人员查询(SELECT/只读)生产数据库的权限?我以前工作过的地方是开发团队db_datareader。我现在工作的地方,开发团队甚至无法连接到生产实例。 测试实例之一是每周一次从生产备份还原的生产副本,因此开发人员实际看到数据没有任何问题。 有什么好的理由不允许开发人员查询生产(除了不希望他们有权读取敏感数据外)?

5
授予用户对所有表的访问权限
我是Postgres的新手,正尝试迁移我们的MySQL数据库。在MySQL中我可以授予SELECT,UPDATE,INSERT,和DELETE在低特权用户的权限,使这些赞助适用于所有表中指定的数据库。我必须在Postgres中缺少一些东西,因为看起来我必须一次为每个表授予一次这些特权。拥有很多数据库,每个数据库有数百个表,这似乎是一项艰巨的任务,只是要起步。此外,一旦数据库开始运行,添加表的频率就足够频繁了,除非绝对必要,否则我不想每次都授予权限。 如何做到最好?

19
在表名中添加'tbl'前缀真的有问题吗?
我正在观看Brent Ozar的一些视频(例如,像这样的视频),他建议不要在表前添加‘tbl’或‘TBL’。 在互联网上,我发现一些博客说它没有为文档添加任何内容,而且“读取它需要更长的时间”。 问题与考虑 这真的有问题吗?因为自从我的第一份dba工作以来,我就在表的前面加上“ tbl”(高级DBA告诉我要对组织进行此操作)。 这是我需要摆脱的东西吗?我进行了一些测试,复制了一个很大的表并为其赋予了'tbl'前缀,而其他表则保留了该表,并且我没有发现任何性能问题。


12
DBA如何才能更“程序员友好”?
关于问题“在数据库层中放置应用程序逻辑或将其放置在数据库层中的参数是什么?”的dba.se版本和programmers.se版本的答案和注释。在某些工作场所中,DBA和程序员之间的鸿沟非常明显。 在这样的问题上,DBA有什么不同的方法可以更好地与程序员合作? 我们应该吗: 研究程序员使用的工具和语言,以了解他们面临的困难,尤其是在使用精心设计的数据库时? 鼓励程序员对数据库进行更好的教育,以及在数据库级别拥有业务逻辑的好处? 更改我们定义数据接口的方式-例如通过使用对程序员更友好的事务性API(例如,针对向后兼容性等问题)?

4
功能表现
由于MySQL的背景,存储过程的性能(较旧的文章)和可用性令人怀疑,我正在为我的公司评估PostgreSQL的新产品。 我想做的一件事是将一些应用程序逻辑移到存储过程中,因此我在这里要求在PostgreSQL(9.0)中使用函数时应做的DO和不做的(最佳实践),特别是关于性能陷阱。

4
存储过程的单元测试
我已经考虑了很长时间了。 基本问题是:如何对存储过程进行单元测试? 我看到我可以相对简单地为经典意义上的函数设置单元测试(我的意思是它们得到零个或多个参数并返回一个值)。但是,如果我考虑一个看似简单的过程的真实示例,该过程似乎在某个位置插入行,并在插入之前或之后执行一些触发器,甚至在定义“单元”的边界时也很难做到。我应该只测试INSERT自身吗?我认为这很简单-价值相对较低。我应该测试整个事件链的结果吗?除了是否要进行单元测试的问题外,设计合适的测试可能是一项艰巨的工作,并且还会增加许多其他问号。 然后是不断更改数据的问题。如果UPDATE影响不只是几行,那么在测试用例中必须以某种方式包括每个可能受影响的行。DELETEs等的进一步困难。 那么如何对存储过程进行单元测试?在复杂性上是否有完全无法实现的极限?维护需要哪些资源? 编辑基于AlexKuznetsov的回答,还有一个小问题:还是有一个完全没有用的阈值?


1
在不停机的情况下进行模式更改和将数据迁移到活动数据库的最佳做法?
如何在不停机的情况下对活动数据库进行架构更改? 例如,假设我有一个PostgreSQL数据库,该数据库的表包含各种用户数据(如电子邮件地址等),这些数据均与特定用户相关联。如果要将电子邮件地址移动到新的专用表中,则必须更改架构,然后将电子邮件数据迁移到新表中。如何在不停止写入原始表的情况下完成此操作?当然,当数据从旧表写入新表时,新数据将继续写入旧表并丢失,对吗? 我猜这个问题经常出现,但是我找不到任何标准的解决方案。 本文解决了这个问题,但是我并没有真正理解步骤3。他说要写入两个表,然后将旧数据从第一个表迁移到新表。您如何确保仅迁移旧数据? (我在Heroku上使用PostgreSQL。)

5
SQL Server维护计划-任务和计划的最佳实践
我的任务是为Sql Server 2005数据库设计维护计划。我知道要进行备份,我想每15分钟执行一次每日完整数据库备份和事务日志备份。我的问题在于弄清楚我想完成哪些其他任务以及应该多久执行一次。 因此,到目前为止,我已经牢记这一点。如果我的想法有任何缺陷或更好的解决方法,请纠正我。 备份-所有表,完整备份(每天) 备份-选定表,完整备份(每小时) 备份-事务日志(每15分钟) 检查数据库完整性(每天) 重组索引(每天) 更新统计信息(每天) 缩小数据库(每周一次) 重建指数(每周) 维护清理(每天) 我记得有一段时间读过(当我在另一份工作中制定类似计划时),其中一些任务不需要每天运行或不应该每天运行。至于哪一个,它逃脱了我。我可以使用一些指导来创建更好的维护计划,以减少灾难中的数据丢失,但在高峰时段运行时不会增加系统负担(也可以提高性能)。

2
具有用户,角色和权限的数据库模型
我有一个带有用户表和角色表的数据库模型。我想控制对多达10个不同元素的访问(权限)。可以将访问权限授予角色或单个用户。以下是用户,角色和项目的表定义: CREATE TABLE users ( id serial NOT NULL PRIMARY KEY, username character varying UNIQUE, password character varying, first_name character varying, last_name character varying, ... ); CREATE TABLE roles ( id serial NOT NULL PRIMARY KEY, name character varying NOT NULL, description character varying, ... ); CREATE TABLE element_1 ( …

3
什么时候创建统计信息而不是创建索引更好?
我发现了很多有关什么 的信息STATISTICS:如何维护它们,如何从查询或索引手动或自动创建它们,等等。但是,我无法找到有关何时使用的任何指导或“最佳做法”信息创建它们:在什么情况下,手动创建的STATISTICS对象比从Index中受益更多。我已经看到了手动创建的筛选统计信息,可以帮助对分区表进行查询(因为为索引创建的统计信息涵盖整个表,而不是每个分区-太小了!),但是肯定还有其他情况可以从统计对象中受益不需要索引的详细信息,也不需要花费维护索引或增加阻塞/死锁机会的成本。 @JonathanFite在评论中提到索引和统计数据之间的区别: 索引将通过创建与表本身排序不同的查找来帮助SQL更快地找到数据。统计信息可帮助SQL确定满足查询所需的内存/工作量。 那是个很棒的信息,主要是因为它可以帮助我阐明我的问题: 如何知道这(或在任何其他技术信息什么 S和如何 S的相关的行为和性质STATISTICS)帮助确定何时选择CREATE STATISTICS在CREATE INDEX创建索引将创建相关的时候,尤其是STATISTICS对象?仅具有统计信息而不具有索引会更好地服务于哪种情况? 如有可能,提供一个工作场景示例,说明该STATISTICS对象比物体更合适,这对超级骗子很有帮助INDEX。 因为我是一个视觉学习者/思想家,所以我认为并排查看es STATISTICS和INDEXes 之间的差异可能会有所帮助,这是帮助确定何时STATISTICS是更好选择的一种可能方法。 Thingy PROs CONs ------- ---------- ------------------- INDEX * Can help sorts. * Takes up space. * Contains data (can * Needs to be maintained (extra I/O). "cover" a query). * More chances for blocking / dead-locks. …

1
在每个T-SQL语句之后执行
在每个SQL语句之后使用GO语句的背后原因是什么?我了解GO表示批处理已结束,并且/或者允许声明声誉,但是在每个声明之后使用它有什么优势。 我只是很好奇,因为很多Microsoft文档等都在每次声明后开始使用它,或者也许我刚刚开始注意到。 还有什么被认为是最佳实践?

1
为BACKUP命令设置BUFFERCOUNT,BLOCKSIZE和MAXTRANSFERSIZE
我找了实际指导的设定值BUFFERCOUNT,BLOCKSIZE以及MAXTRANSFERSIZE该的BACKUP命令。我做了一些研究(见下文),做了一些测试,并且我完全意识到,任何真正有价值的答案都将以“嗯,这取决于……”开始。我对已经完成的测试以及在我发现的任何资源中显示的测试的担忧(请参见下面的方法)是测试是在真空中完成的,很可能是在没有其他负载的系统上进行的。 我对基于长期经验的这三个选项的正确指导/最佳实践感到好奇:数周或数月的许多数据点。我并没有在寻找特定的值,因为这主要是可用硬件的功能,但是我想知道: 各种硬件/负载因素如何影响应采取的措施。 在任何情况下都不应该覆盖这些值吗? 是否有一些陷阱可以覆盖所有这些并非立即显而易见的陷阱?占用过多的内存和/或磁盘I / O?还原操作复杂吗? 如果我有一台运行着多个SQL Server实例的服务器(一个默认实例和两个命名实例),并且如果我同时运行所有3个实例的备份,那么除了确保集合(BUFFERCOUNT* MAXTRANSFERSIZE)没有超过可用的RAM?可能的I / O争用? 在将三个实例放在一台服务器上并再次在所有三个实例上同时运行备份的相同场景中,在每个实例内同时运行多个数据库的备份又将如何影响这些值的设置?这意味着,如果三个实例中的每个实例每个都有100个数据库,则每个实例每个实例同时运行2或3个备份,这样就可以同时运行6到9个备份。(在这种情况下,我有许多中小型数据库,而不是几个大型数据库。) 到目前为止,我收集了以下内容: BLOCKSIZE: 支持的大小为512、1024、2048、4096、8192、16384、32768和65536(64 KB)字节。[1] 磁带设备的默认值为65536,否则为512 [1] 如果要备份要复制到CD-ROM并从CD-ROM还原的备份,请指定BLOCKSIZE = 2048 [1] 当您写入单个磁盘时,默认值为512就可以了。如果使用RAID阵列或SAN,则必须进行测试以查看默认值还是65536更好。[13(第18页)] 如果手动设置,则该值必须> =用于创建数据文件的块大小,否则将出现以下错误: 消息3272,级别16,状态0,第3行 'C:\ Program Files \ Microsoft SQL Server \ MSSQL11.MSSQLSERVER \ MSSQL \ Backup \ BackupTest.bak'设备的硬件扇区大小为4096,但是block size参数指定不兼容的覆盖值512。使用兼容的块大小重新发出该语句。 BUFFERCOUNT: 默认值[2],[8]: SQL Server 2005及更高版本: (NumberofBackupDevices * …

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.