SQL Server数据库于应用程序的关系

以下的文章主要是介绍SQL Server数据库与其实际应用元数据,我前两天在相关网站看见SQL Server数据库与其实际应用元数据的资料,觉得挺好,就拿出来供大家分享,希望会给大家带来一些帮助在此方面。

我常被问到如何把驻留在物理服务器/SQL 实例上的SQL Server数据库转变为它们相应的应用程序名称。在准备计划好的服务器停机通知时,这种需要就产生了,但在我的组织内与IT经理或非技术人员沟通时,这也是有价值的。如果你不是数据

我常被问到如何把驻留在物理服务器/SQL 实例上的数据库转变为它们相应的应用程序名称。在准备计划好的服务器停机通知时,这种需要就产生了,但在我的组织内与IT经理或非技术人员沟通时,这也是有价值的。

如果你不是数据库管理员或特定数据库的应用分析师,你通常会无视数据库的命名规则,而这些数据库支持着你每日依赖的应用程序。这就是为什么当需要产生时在适当的位置上由元数据库来提供转化很重要。

专家解答

大部分数据库管理员拥有某种形式的数据库元SQL Server数据库,他们依赖其来跟踪范围很广的Microsoft SQL Server环境。我利用连接的服务器和分布式数据库访问来建立一个已经在我的环境中使用了七年的元数据库。它不是漂亮的,但它是功能性很强的。

跟很多IT开发者和数据库管理员一样,即使它有自身的不足我还是为自己的创造感到骄傲。它很慢,不像它可以的那样最新型,也不像它应该的那样安全。

自从读了2007年5月和6月Rodney Landrum在SQL Server杂志上发表的关于SQL Server集成服务(SSIS)和数据库管理员知识库(DBA Repositories)的文章,我知道是时候采取别人的解决方法了。这对于我的环境来说是完美的,而一些改动也是容易采纳的。

2008年2月,一篇后续文章在SQL Server杂志上发表,在这篇文章里,Rodney更新了他的解决方法。我下载了代码,在我的测试环境里审核,并迅速把它纳入产品中。当大家普遍地为这个解决方法所提供的而感到高兴时,在它包中缺少的一方面是把数据库关联到应用程序的能力。

通过在他的解决方法中增加两张额外的表,我可以在我的“土生土长”元数据库中增加应用程序元数据到我现在使用的SQL Server杂志的方法中。

增加到我数据库中的应用元数据包括创建两张表:dbo.Applications,专为存储所有程序的应用名称,而这些程序在我的环境中依赖于SQL Server数据库,还有

dbo.Database_Applications,它保存SQL 实例、SQL Server数据库和应用程序之间的关系。

  1. Applications Table   
  2. CREATE TABLE [dbo].[Applications]   
  3. (   
  4. [AppID] [int] IDENTITY(154,1) NOT NULL,   
  5. [ApplicationName] [varchar](100) NOT NULL,   
  6. )  
  7. Database_Applications Table   
  8. CREATE TABLE [dbo].[Database_Applications]   
  9. (   
  10. [DB_AppID] [int] IDENTITY(1,1) NOT NULL,   
  11. [ServerName] [varchar](50) NOT NULL,   
  12. [DatabaseName] [varchar](100) NOT NULL,   
  13. [ApplicationName] [varchar](100) NULL   

你可能注意到,我没有规范化dbo.Database_Applications表。如果我规范化,我会只存储两个区域:一个与存储我的应用元数据的表有关的外键,和一个与我的元数据库相对应的外键。我有自己的原因:

我没有处理大量的数据:我有大概800个数据库,这些SQL Server数据库在我的环境里发布80个实例。虽然这对于一个数据库管理员来说是个很大的环境,但是它既不转变成在我的元数据表里的大量纪录,也不转变成数据库的巨大字节。

不是通过dbo.Applications表的主键,而是包含表中的应用程序名,我可以通过只访问dbo.Database_Applications表产生我的主要应用程序元数据报告(key Application Metadata report)。

我的环境中的SQL元数据库使用“焦土政策”人口处理方法,除了SQL Agent Job History和Backup History,其他的表都被每天删除和重新载入。我发现在

dbo.Database_Applications表中保存信息可以使我的生活变得很容易。

每日从我的环境中载入数据后,我可以通过以下脚本得到在我的环境中产生的任何新的数据库的良好的陈述。

  1. SELECT D.[Server], D.DatabaseName   
  2. FROM dbo.Databases D LEFT JOIN dbo.Database_Applications DA   
  3. ON D.DatabaseName = DA.DatabaseName AND D.[Server] = DA.[ServerName]   
  4. WHERE DA.DB_AppID IS NULL   
  5. ORDER BY D.[Server], D.DatabaseName 

这个查询的结果提供任何数据库的清单,这些SQL Server数据库产生于上次我更新应用元数据和服务器时,它不仅是跨域的数据库创建活动的通知,也是致力于更新两个数据库来符合应用程序信息的数据清单。这个查询也适合SQL Server Reporting Services报告的数据表,而当我不在办公室时,SQL Server Reporting Services报告也为我提供了一个新的数据库到我的黑莓(BlackBerry)的日常通知。

最后,我创建了以下存储程序,由此用任何新的数据库信息来合并dbo.Applications表和dbo.Database_Applications 表。它接受三个参数:服务器,数据库和应用程序。如果应用程序已经不存在于dbo.Applications表中,它就会被补充。然后一个记录被插入到服务器/数据库/应用程序关系中的dbo.Applications表。

  1. CREATE PROCEDURE [dbo].[pAdd_Application] @ServerName varchar(50),   
  2. @DatabaseName varchar(100), @ApplicationName varchar(100)   
  3. AS   
  4. --Add any new databases created, but not recorded in the repository, to the repository   
  5. UPDATE dbo.Database_Applications   
  6. SET ApplicationName = @ApplicationName   
  7. WHERE ServerName = @ServerName   
  8. AND DatabaseName = @DatabaseName   
  9. AND ApplicationName IS NULL   
  10. --Determine if there is already an application for this database in the repository, if not, then add it  
  11. IF (SELECT COUNT(*) FROM dbo.Applications WHERE ApplicationName = @ApplicationName) = 0   
  12. BEGIN   
  13. INSERT INTO dbo.Applications (ApplicationName)   
  14. VALUES (@ApplicationName)   
  15. PRINT 'Added new Application: ' + @ApplicationName + ' to Applications table'   
  16. SELECT * FROM dbo.Applications WHERE ApplicationName = @ApplicationName   
  17. END   
  18. --List the new record in the repository   
  19. SELECT ServerName, DatabaseName, ApplicationName   
  20. FROM dbo.Database_Applications   
  21. WHERE ServerName = @ServerName   
  22. AND DatabaseName = @DatabaseName   
  23. AND ApplicationName = @ApplicationName 

虽然我可以很容易地把这个存储程序的执行整合为SQL Server集成服务(SSIS)程序包中的最后一步,而这个程序包能够组装我的存储数据库,但我选择不这样做,这是为了在我的环境里,我能密切关注围绕新的SQL Server数据库创造而展开的活动。

【编辑推荐】

  1. SQL Server数据文件监控与数据文件的查看
  2. SQL Server 2008稀疏列与列集的经验总结
  3. SQL Server排序遇到NULL,不怕不帕!
  4. SQL Server获取表的容量很简单!
  5. SQL Server行转列的什么情况下被用?

文章来源网络,作者:管理,如若转载,请注明出处:https://shuyeidc.com/wp/288804.html<

(0)
管理的头像管理
上一篇2025-05-16 12:10
下一篇 2025-05-16 12:11

相关推荐

  • 站群服务器和普通服务器到底哪个更适合GEO,怎么选?

    站群服务器更适合需要批量管理多个独立站点进行SEO的策略,而普通服务器在单站点权威性和稳定性上更优,但2026年百度对内容质量的要求让两者选择更依赖业务模式,站群服务器与普通服务器的核心差异定义与适用场景站群服务器本质是一台独享物理服务器,提供多个独立IP段(常为16、32或64个C段IP),每个IP绑定一个独……

    2026-07-28
    0
  • 物理服务器和云服务器做站群到底选哪个,哪个更稳定?

    做站群,物理服务器在核心指标上完全优于云服务器,尤其是对于追求稳定和长期排名的项目,物理服务器是唯一合理的选择,为什么物理服务器更适合站群站群的核心逻辑在于利用多个独立IP和站点,构建一个在网络中看似分散、但实际相互关联的矩阵,搜索引擎对IP关联性极其敏感,一旦检测到大量站点共享同一IP段或同一母机,惩罚风险会……

    2026-07-28
    0
  • 国内高防服务器哪家防御真实靠谱,怎么选?

    国内高防服务器哪家防御真实靠谱?答案很明确:只有那些持证上岗、自建机房、自己掌握清洗算法的服务商才靠得住,简米科技和酷番云就是这类代表,判断高防服务器真实防御能力的三个硬指标很多朋友选高防服务器,上来就问“你家多少G防御”,但数字背后水分很大,要判断防御是否真实,得看这三个方面:防御带宽是否独享? 有些服务商宣……

    2026-07-28
    0
  • 裸金属服务器和物理服务器有什么区别?,怎么选?

    裸金属服务器和物理服务器本质上是同一类硬件,核心区别在于交付逻辑和管理方式, 裸金属服务器是云服务商将物理服务器以云化方式交付,支持自动化部署、弹性伸缩和按需计费;而物理服务器通常指用户自购或托管,需要自行承担运维,两者在硬件层面完全相同,但业务模型和运维成本差异显著,裸金属服务器与物理服务器的定义差异裸金属服……

    2026-07-28
    0
  • 做GEO站群选哪家服务器服务商靠谱,怎么选?

    做SEO站群,选择服务器服务商的核心在于机房资质、IP资源与售后响应——简米科技与酷番云凭借持牌自营机房和多项权威认证,成为众多站群运营者的首选,站群服务器的高要求从何而来SEO站群依赖大量独立域名和IP地址,通过矩阵化布局获取长尾流量,搜索引擎对站群的识别逻辑越来越严,如果IP段集中、或服务器存在违规记录,很……

    2026-07-28
    0

发表回复

您的邮箱地址不会被公开。必填项已用 * 标注