Understanding Teradata In SharePoint Development – Part 1
I have been working with Teradata now in a SharePoint context for almost a half a year now exclusivly. While Teradata is only useful for companies that process large, actually enormous segements of data, it seems that a lot of companies that are using Teradata are also using SharePoint as their choice for collaboration software. Lot’s of airlines use it around Minneapolis for example. Some of the larger retail stores with HQ’s based out of MN cities also use it. Using SharePoint as the display vehicle for Teradata is actually fairly straightfoward, since Teradata provides a strongly typed client object model that is fairly easy to interface out into a Design by Contract (DbC) programming paradigm. After that you treat the data like you are reading out of any standard data source outside of particular type casting it goes on as business as usual.
Teradata is like most other relatinal database systems, however there are some important differences that exist. And like most commercial database systems, there are 50,000 different tooling packages that can encompass the naming convention. TO narrow things down a bit, I am really only going to look at the warehousing and storage components of Teradata, because it’s all I work with! Teradata invokes the concept of using multi processing units in parellel, called Massively Parellel Computing, in order to cultivate its high speed rate. As part of this, it also provides mutual exclusion between the said systems by using Shared Nothing architecture, whereby all units that are involved in the processing have their own assets. This concept has been around for a while, Google uses it and refers to the implementation as Sharding. The benefit of Sharding is notable in that it lends itself to large levels of scalability. Since Teradata touts that it deals with Big Data, a term coined in 2010, you can see where the capabilities of it target this particular market.
Like every other relational database system, Teradata allows you to store, manipulate, and pivot data within a store. Where Teradata is unique is using off the shelf technology approaches, it was developed to support an acrynom parade. Teradata acts as a massivley parellel machine (going back to massivel parellel computing concept) through an interconnect structure that supports symmetric multi processing (SMP) and massive parellel processing (MPP). Within this concept, going back to the Shared Nothing concept the mutually exlusion elimnates the need for various type of databases on various platforms.
As a SharePoint developer using Teradata for the first time, it is important to know that within the Active Teradata warehouse, there are two types of queries. There are Strategic Queries, or queries that are generally combine several operations and are generally intensive chained methods (generally one-off queries as well), and Tactical Queries, or queries that are more tuned for decision making and are generally written using a time vector as a means to calculate the effectivness of the query. This no different than the queries that are written for SQL, just a simple expansion of semantics.
In the next post, I will expand more on Teradata concepts. Following, I will start to write some SharePoint code against a test Teradata platform.