Home Page for the TeradataForum
 

Archives of the TeradataForum

Message Posted: Wed, 22 Oct 2003 @ 14:33:23 GMT


     
  <Prev Next>   <<First <Prev Next> Last>>  


Subj:   Re: References
 
From:   Chris Coffing

Dieter

Great questions...


  Why? Column createtext in dbc.tvm already includes all DDL except for Tables and SPs.  


The reason is that we need to have all the DDL information and have found that the CreatText field is sometimes NULL or only has a portion of the DDL. In regards to tables, it captures the alter statement in the creattext field and so we do not have the table DDL for our use. (We use this DDL information in our Configuration Management and Recovery solutions.)

We use the Delta-Processing to determine what has changed on a daily basis. The data dictionary is a real-time storage area and does not capture change.

We can determine what changes have occurred in our warehouse on a daily basis and research these changes based on every time we pull the system. (This is daily at this time)

We want to get the Stored Proc's so we can determine if these procedures will break or if they are already broken. It has worked rather well.


  Did you ever try Metadata Services? It's a part of Teradata and provides all those information.  


Yes. Metadata Services is a nice solution but it runs on Teradata and most of our customer base is interested in maintaining their Metadata off of the Teradata platform. We also do a lot of customization to our solution to meet the portal requirements of our customers.

We have asked the same questions to our customer base and get a variety of answers. I believe the bottom line on MDS or any other MetaData solution is Time and Focus. This is something that our customers are off-loading to us.


  How does the knowledge about referencing objects helps you to define which table to drop?  


We all know that Data Warehousing is a huge animal. There are too many areas to be an expert in them all. We use our object reference information to communicate to the proper subject matter experts (developers, DBAs, Management and Functional personnel) to ask questions and walk through what happens when decisions are made to drop objects.

It provides a great visual representation of what may break if a table or view is dropped.

The reason why so many objects remain in the warehouse and are not cleaned up is because there is no confidence in what these objects touch. It has become an industry standard to simply by more disks, once again costing the company more money.

This method provides a way for everyone to get on the same page and make educated decisions with confidence.

Remember. We all have a valuable piece of the warehousing puzzle but very few have the whole picture. If you can get the pieces that you need to come together, then you can make decisions and get things done quickly.


Here is one more interesting value proposition.

I have experienced when views are created using a "SELECT *" that these views will break when a table column is either altered or a column is removed (same as altered I know) except the view will not break if a column is added to the table.

The view however will not show the newly added column until the view is replaced using the "SELECT *" method, or any other method for that matter.

Since this is the case for views, we use the object reference information to determine what we need to touch after we make changes to the tables in the warehouse.

We have several internal customers that have certain security rights assigned to them based on views. This means we may have 5 or more views that do the same thing with a slight difference for security concerns. When changes are made to the tables, we must determine what we must adjust across the entire warehouse before we deploy the changes.

This effort use to take me weeks and now takes me a few minutes. When they say "Knowledge is Power", they mean it.

Sorry for being so long winded, but you did ask.

Chris Coffing
Senior Vice President
Coffing Data Warehousing
www.coffingdw.com



     
  <Prev Next>   <<First <Prev Next> Last>>  
 
 
 
 
 
 
 
 
  
  Top Home Privacy Feedback  
 
 
Copyright for the TeradataForum (TDATA-L), Manta BlueSky    
Copyright 2016 - All Rights Reserved    
Last Modified: 15 Jun 2023