Beginner Database Design & SQL Programming Using Microsoft SQL Server 2014

Kalman Toth

  • 出版商: CreateSpace Independ
  • 出版日期: 2014-05-01
  • 售價: $1,320
  • 貴賓價: 9.5$1,254
  • 語言: 英文
  • 頁數: 606
  • 裝訂: Paperback
  • ISBN: 1499321732
  • ISBN-13: 9781499321739
  • 相關分類: MSSQLSQL資料庫
  • 海外代購書籍(需單獨結帳)

相關主題

商品描述

Learn Microsoft Database Design & SQL Server 2014 Programming! SQL Server 2014 follows just in 2 years after SQL Server 2012 with very exciting new features. One on the top: in-memory OLTP tables for superior performance. With abundant computer memory, why keep tables on slow disk? Developers across the world face database issues daily. While immersed in procedural languages with loops, RDBMS forces them to think in terms of sets without loops. It takes transition. It takes training. It takes experience. Developers are exposed also to Excel worksheets, or spreadsheets, as they were called in the not so distant past. So, if you know worksheets, how hard can databases be? After all, worksheets look pretty much like database tables, don’t they? The big difference is the connections among well-designed tables. A database is a set of connected tables, which represent entities in the real world. A database can be 100 connected tables or 3000. The connection is very simple: row A in table Alpha has affiliated data with row B in table Beta. However, even with 200 tables and 300 connections (FOREIGN KEY references), it takes a good amount of time to become familiar to the point of having an acceptable working knowledge. "The Cemetery of Computer Languages" is expanding. You can see tombstones like PL/1, Forth, Ada, Pascal, LISP, RPG, APL, SNOBOL, JOVIAL, Algol – the list goes on. For some, the future is in question: PowerBuilder, ColdFusion, FORTRAN and COBOL. On the other hand, SQL is running strong after 3 decades of glorious existence. What is the difference? The basic difference is that SQL can handle large datasets in a consistent manner based on mathematical foundations. You can throw together a computer language easily: assignment statements, looping, if-then conditional, 300 library functions, and voila! Here is the new language: Mars/1, named after the red planet to be fashionable with NASA's new Mars robot. However, can Mars/1 JOIN a table of 1 million rows with a table of 10 million rows in a second? The success of SQL language is so compelling that other technologies are tagged onto it like XML/XQuery, which deals with semi-structured information objects. In SQL you are thinking at a high level. In C# or Java, you are dealing with details – lots of them. That is the major difference. Why is so much of the book dedicated to database design? Why not plunge into SQL coding and eventually the developer will get a hang of the design? Because high-level thinking requires thinking at the database design level. A farmer has six mules. H how do we model it in the database? We design the Farmer and FarmAnimal tables, and then connect them with FarmerID FOREIGN KEY in FarmAnimal referencing the FarmerID PRIMARY KEY in the Farmer table. What is the big deal about it? It looks so simple. In fact, how about just calling the tables Table1 and Table2 to be more generic. Ouch! Meaningful naming is the very basis of good database design. Relational database design is truly simple for simple well-understood models. The challenge starts in modeling complex objects such as financial derivative instruments, airplane passenger scheduling, or a social network website. When you need to add 5 new tables to a 1000 table database and hook them in (define FOREIGN KEY references) correctly, it is a huge challenge. To begin with, some of the five new tables may already be redundant, but you don't know that until you understand what the 1000 tables are really storing. Frequently, learning the application area is the biggest challenge for a developer when starting a new job. The SQL language is simple to program and read even when touching 10 tables. Complexities abound though. The very first one: does the SQL statement touch the right data set – 999 records and 1000 or 998? T-SQL statements are turned into Transact-SQL scripts, stored procedures, and user-defined functions, and trigger server-side database objects.

商品描述(中文翻譯)

學習微軟資料庫設計和SQL Server 2014程式設計!SQL Server 2014在SQL Server 2012之後僅僅兩年推出,帶來了非常令人興奮的新功能。其中一個頂尖功能是用於提升性能的內存OLTP表。有了豐富的計算機內存,為什麼要將表格存儲在慢速磁盤上呢?

全球的開發人員每天都面臨著數據庫問題。當他們沉浸在具有循環的程序語言中時,關聯式數據庫管理系統(RDBMS)迫使他們以集合而不是循環的方式思考。這需要轉變,需要培訓,需要經驗。

開發人員還接觸到Excel工作表,或者在不久的過去被稱為電子表格。所以,如果你懂得工作表,數據庫有多難呢?畢竟,工作表看起來很像數據庫表格,對吧?

最大的區別在於精心設計的表格之間的連接。數據庫是一組相互連接的表格,這些表格代表現實世界中的實體。一個數據庫可以有100個連接的表格,也可以有3000個。連接非常簡單:表格Alpha中的行A與表格Beta中的行B有關聯的數據。然而,即使有200個表格和300個連接(外鍵引用),要熟悉到具有可接受的工作知識的程度還需要相當長的時間。

"計算機語言墓地"正在擴大。你可以看到像PL/1、Forth、Ada、Pascal、LISP、RPG、APL、SNOBOL、JOVIAL、Algol等墓碑。對於一些語言,未來是個問題:PowerBuilder、ColdFusion、FORTRAN和COBOL。

另一方面,SQL在光榮存在的30年後仍然強勁運行。差別在哪裡?基本差別在於SQL可以基於數學基礎以一致的方式處理大型數據集。你可以輕易地組合一個計算機語言:賦值語句、循環、if-then條件語句、300個庫函數,然後就有了新語言:Mars/1,以紅色星球命名,以迎合NASA的新火星機器人。然而,Mars/1能在一秒內將一個有100萬行的表格與一個有1000萬行的表格JOIN起來嗎?SQL語言的成功如此令人信服,以至於其他技術也被附加到其中,例如處理半結構化信息對象的XML/XQuery。在SQL中,你是在高層次思考。在C#或Java中,你處理的是細節 - 很多細節。這是主要的區別。

為什麼這本書如此多的篇幅都專注於數據庫設計?為什麼不直接進入SQL編程,最終開發人員會掌握設計的要點?因為高層次思考需要在數據庫設計層面進行思考。一個農夫有六匹騾子。我們如何在數據庫中建模呢?我們設計了農夫和農場動物表格,然後通過FarmAnimal表格中的FarmerID外鍵引用Farmer表格中的FarmerID主鍵來將它們連接起來。這有什麼大不了的?看起來很簡單。事實上,直接稱呼這些表格為Table1和Table2是否更通用一些。哎呀!有意義的命名是良好數據庫設計的基礎。對於簡單且易於理解的模型,關聯式數據庫設計確實很簡單。挑戰在於對複雜對象進行建模,例如金融衍生工具、飛機乘客排班或社交網絡網站。當你需要向一個有1000個表格的數據庫中添加5個新表格並正確地連接它們(定義外鍵引用)時,這是一個巨大的挑戰。首先,這五個新表格中的一些可能已經是多餘的,但在你了解這1000個表格實際存儲的內容之前,你不知道這一點。對於開發人員來說,瞭解應用領域通常是開始新工作時面臨的最大挑戰。

即使涉及到10個表格,SQL語言的編程和閱讀也很簡單。然而,複雜性仍然存在。第一個問題是:SQL語句是否涉及正確的數據集 - 999條記錄和1000或998條?T-SQL語句被轉換為Transact-SQL腳本、存儲過程和用戶定義函數,以及觸發器等服務器端數據庫對象。