Quick Search for:  in language:    
RDBMS,Here,concept,Store,alias,simple,terms,r
   Code/Articles » |  Newest/Best » |  Community » |  Jobs » |  Other » |  Goto » | 
CategoriesSearch Newest CodeCoding ContestCode of the DayAsk A ProJobsUpload
SQL Stats

 Code: 44,501. lines
 Jobs: 125. postings

 How to support the site

 
Sponsored by:

 
You are in:
 
Login





Latest Code Ticker for SQL
Beginners pack
By hardik shah on 1/11


Inline Views
By Thivya Prabakaran on 1/6


Create thousand Data Base users quickly
By N.D.I.Samantha on 1/1


Numbers from String
By Jeff Michelson on 12/30


Click here to put this ticker on your site!


Add this ticker to your desktop!


Daily Code Email
To join the 'Code of the Day' Mailing List click here!

Affiliate Sites



 
 
   

Store Key – New RDBMS Concept in MS SQL SERVER 2000

Print
Email
 

Submitted on: 8/27/2003 1:23:31 AM
By: Raghavendra Narayana 
Level: Advanced
User Rating: Unrated
Compatibility:SQL Server 2000

Users have accessed this article 2281 times.
 

(About the author)
 
     Here is a new RDBMS concept, “Store Key” alias “SK”. In simple terms you store all the redundant data of a database in one table and use it whenever/wherever required via “Store Key ID” alias “SKID”. This article targets the redundant data as well as RDBMS Normalization concept. The base idea of normalization is storing the redundant data in another table and creating a link between the divided tables. Normally we store the redundant data in Table X and have the Foreign Key relation to the actual column in Table Y. The SK concept is simple, instead of creating one table per one such relation; create a single table for a database, store all the redundant data there. This reduces the cost/maintenance of tables, Primary Keys, Indexes and etc.

This article has accompanying files

 
 
Terms of Agreement:   
By using this article, you agree to the following terms...   
1) You may use this article in your own programs (and may compile it into a program and distribute it in compiled format for languages that allow it) freely and with no charge.   
2) You MAY NOT redistribute this article (for example to a web site) without written permission from the original author. Failure to do so is a violation of copyright laws.   
3) You may link to this article from another website, but ONLY if it is not wrapped in a frame. 
4) You will abide by any additional copyright restrictions which the author may have placed in the article or article's description.
DOWNLOAD THE ATTACHED ZIP FILE FOR COMPLETE ARTICLE. Store Key – New RDBMS concept in MS SQL SERVER 2000 RAGHAVENDRA NARAYANA RAGHAVENDRA NARAYANA 2 1346 2003-08-27T05:17:00Z 2003-08-27T05:17:00Z 8 1302 7426 TFRB 61 14 9119 9.2720

Store Key – New RDBMS Concept in MS SQL SERVER 2000

Here is a new RDBMS concept, “Store Key” alias “SK”. In simple terms you store all the redundant data of a database in one table and use it whenever/wherever required via “Store Key ID” alias “SKID”.

This article targets the redundant data as well as RDBMS Normalization concept. The base idea of normalization is storing the redundant data in another table and creating a link between the divided tables. Normally we store the redundant data in Table X and have the Foreign Key relation to the actual column in Table Y. The SK concept is simple, instead of creating one table per one such relation; create a single table for a database, store all the redundant data there. This reduces the cost/maintenance of tables, Primary Keys, Indexes and etc.

Let us call the table that stores redundant data as “SKTABLE”.

SKTABLE Structure:

Column Name

Data Type

Description

SKID

INT [IDENTITY COLUMN]

Store Key ID. Unique identification number of the Data column

DATA

VARCHAR

The actual data

By creating Stored Procedures/functions/triggers, we can deal with data transaction between actual table columns and SKTABLE data.

Let us take up couple of examples to show how SK can be implemented. In both the examples “INSTEAD OF Trigger” feature SQL SERVER 2000 is used. Note that I am focusing on the SK concept rather than the way of achieving it, there might be better ways of doing it.

Examples

Example 1: This targets redundant data. Assume that you have two tables Candidate and Employer, both stores address of Candidates and Companies respectively. Both the tables include Address1, Address2 columns. Let us apply Store Key concept for this.

The UPDATE and DELETE SQL is not handled in this example.

Script:

--SKTable Table

IF EXISTS (SELECT * FROM DBO.SYSOBJECTS WHERE ID = OBJECT_ID(N'[DBO].[SKTABLE]') AND OBJECTPROPERTY(ID, N'ISUSERTABLE') = 1)

TRUNCATE TABLE DBO.SKTABLE

ELSE

CREATE TABLE DBO.SKTABLE

(SKID int IDENTITY (1,1) NOT NULL,

DATA varchar(2000) NULL)

GO

--Candidate Table

CREATE TABLE DBO.CANDIDATE

(CANDIDATENAME VARCHAR(25),

ADDRESS1 VARCHAR(50),

ADDRESS2 VARCHAR(50))

--Employer Table

CREATE TABLE DBO.EMPLOYER

(EMPLOYERNAME VARCHAR(25),

ADDRESS1 VARCHAR(50),

ADDRESS2 VARCHAR(50))

--Trigger on Candidate Table

CREATE TRIGGER DBO.TSKCAND ON DBO.CANDIDATE INSTEAD OF INSERT AS

BEGIN

--Variable to store the Unique ID of Data

DECLARE @sSKID AS CHAR(10)

--Check the inserting data already exist in Store Key Table

SELECT @sSKID = LTRIM(RTRIM(STR(SKID))) FROM DBO.SKTABLE WHERE DATA IN (SELECT ADDRESS2 FROM INSERTED)

IF @@ROWCOUNT = 0

BEGIN

--If the Data being inserted does not exist in SKTable, create one

INSERT INTO DBO.SKTABLE (DATA) SELECT ADDRESS2 FROM INSERTED

SELECT @sSKID = LTRIM(RTRIM(STR(MAX(SKID)))) FROM DBO.SKTABLE

END

INSERT DBO.CANDIDATE(CANDIDATENAME, ADDRESS1, ADDRESS2)

SELECT CANDIDATENAME, ADDRESS1, @sSKID FROM INSERTED

END

--Trigger on Employer table

CREATE TRIGGER DBO.TSKEMP ON DBO.EMPLOYER INSTEAD OF INSERT AS

BEGIN

--Variable to store the Unique ID of Data

DECLARE @sSKID AS CHAR(10)

--Check the inserting data already exist in Store Key Table

SELECT @sSKID = LTRIM(RTRIM(STR(SKID))) FROM DBO.SKTABLE WHERE DATA IN (SELECT ADDRESS2 FROM INSERTED)

IF @@ROWCOUNT = 0

BEGIN

--If the Data being inserted does not exist in SKTable, create one

INSERT INTO DBO.SKTABLE (DATA) SELECT ADDRESS2 FROM INSERTED

SELECT @sSKID = LTRIM(RTRIM(STR(MAX(SKID)))) FROM DBO.SKTABLE

END

INSERT DBO.EMPLOYER(EMPLOYERNAME, ADDRESS1, ADDRESS2)

SELECT EMPLOYERNAME, ADDRESS1, @sSKID FROM INSERTED

END

Now, insert some rows and see how Store Key concept works.

--FOLLOWING 2 SQLS CREATES 2 ENTRIES IN SKTABLE

INSERT INTO DBO.CANDIDATE (CANDIDATENAME, ADDRESS1, ADDRESS2)

VALUES ('RAJEEV RAO', '#15, 1ST CROSS', 'BANASHANKARI')

INSERT INTO DBO.CANDIDATE (CANDIDATENAME, ADDRESS1, ADDRESS2)

VALUES ('SANTOSH XAVIER', '#30, 3RD CROSS', 'MG ROAD')

--FOLLOWING 2 SQLS USES WILL NOT CREATE ENTRIES IN SKTABLE

--AS IT ADDRESS2 ENTRIES EXISTS IN SKTABLE. IT JUST INSERTS SKID REFERENCE.

INSERT INTO DBO.EMPLOYER (EMPLOYERNAME, ADDRESS1, ADDRESS2)

VALUES ('THOMSON FINANCIAL', '#15, BAHAIS BHAVAN ROAD', 'MG ROAD')

INSERT INTO DBO.EMPLOYER (EMPLOYERNAME, ADDRESS1, ADDRESS2)

VALUES ('WORLDSCOPE DISCLOSURE', '100, DVG ROAD', 'BANASHANKARI')

--FOLLOWING SQL CREATES AN ENTRY IN SKTABLE AS ADDRESS2 IS NEW HERE

INSERT INTO DBO.EMPLOYER (EMPLOYERNAME, ADDRESS1, ADDRESS2)

VALUES ('PRIMARK INDIA PVT LTD', '25, 5TH MAIN', 'KORAMANGALA')

<--[if gte vml 1]> <--[if gte mso 9]>

Example 2: This targets Normalization concept. Assume that you have Employee and Department details in one table; you decided to normalize it to two tables i.e. Employee and Department. Let us apply Store Key concept for this instead dividing it into two tables.

The Employee table stores Department name also with other information about employee, by making Department Name column as SK column we can store Department Names in SKTable and have SKID reference in Employee table.

Add/Edit the entries in Employee table that in turn add/edit respective entries in SKTABLE as well.

The DELETE SQL is not handled in this example.

Script:

Note: The script creates objects under DBO owner. Change it if required.

--SKTable table

IF EXISTS (SELECT * FROM DBO.SYSOBJECTS WHERE ID = OBJECT_ID(N'[DBO].[SKTABLE]') AND OBJECTPROPERTY(ID, N'ISUSERTABLE') = 1)

TRUNCATE TABLE DBO.SKTABLE

ELSE

CREATE TABLE DBO.SKTABLE

(SKID int IDENTITY (1,1) NOT NULL,

DATA varchar(2000) NULL)

GO

--Employee table

CREATE TABLE DBO.Employee (

EMPCODE char (10) NOT NULL,

EMPNAME varchar (25) NULL,

DEPTCODE char (10) NULL --Store Key Column

)

GO

--Trigger on Employee table

CREATE TRIGGER DBO.TSKDEPT ON DBO.EMPLOYEE INSTEAD OF INSERT, UPDATE AS

BEGIN

--Variable to store the Unique ID of Data

DECLARE @sSKID AS CHAR(10)

--Variable to identify the transaction as UPDATE/INSERT

DECLARE @IUPSERT AS INT

--If Deleted table contains 0 rows then it is an insert sql

SELECT @IUPSERT = COUNT(1) FROM DELETED

--Check the inserting data already exist in Store Key Table

SELECT @sSKID = LTRIM(RTRIM(STR(SKID))) FROM DBO.SKTABLE WHERE DATA IN (SELECT DEPTCODE FROM INSERTED)

IF @@ROWCOUNT = 0

BEGIN

--If the Data being inserted does not exist in SKTable, create one

INSERT INTO DBO.SKTABLE (DATA) SELECT DEPTCODE FROM INSERTED

SELECT @sSKID = LTRIM(RTRIM(STR(MAX(SKID)))) FROM DBO.SKTABLE

END

--Triggered for Insert SQL

IF @IUPSERT = 0

BEGIN

INSERT DBO.EMPLOYEE(EMPCODE, EMPNAME, DEPTCODE)

SELECT EMPCODE, EMPNAME, @sSKID FROM INSERTED

END

ELSE

--Triggered for Update SQL

BEGIN

UPDATE DBO.EMPLOYEE

SET EMPCODE = INSERTED.EMPCODE, EMPNAME = INSERTED.EMPNAME, DEPTCODE = @sSKID

FROM DBO.EMPLOYEE, INSERTED

WHERE DBO.EMPLOYEE.EMPCODE = INSERTED.EMPCODE AND DBO.EMPLOYEE.EMPNAME = INSERTED.EMPNAME

END

END

Now insert some rows and see how Store Key concept works. The beauty here is you just need to insert the actual value itself e.g. if the department name is ‘PRODUCTION’ insert it as it is, Store Key takes care of allocating SKID and storing the SKID instead of ‘PRODUCTION’.

--THE FOLLOWING 3 INSERT STATEMENT CREATES 3 ROWS IN EMPLOYEE AND SKTABLE TABLES

INSERT INTO DBO.EMPLOYEE (EMPCODE, EMPNAME, DEPTCODE)

VALUES ('EMP1', 'BHASKER SATYAMURTHY', 'TECHNOLOGY')

INSERT INTO DBO.EMPLOYEE (EMPCODE, EMPNAME, DEPTCODE)

VALUES ('EMP2', 'JOSEPH JEUNE', 'ACCOUNTS')

INSERT INTO DBO.EMPLOYEE (EMPCODE, EMPNAME, DEPTCODE)

VALUES ('EMP3', 'VIJAY SHARMA', 'PRODUCTION')

--THE FOLLOWING 2 INSERT STATEMENT WILL NOT CREATE ROW IN SKTABLE

--AS THE DEPTCODE WE ARE GIVING ALREADY EXIST

INSERT INTO DBO.EMPLOYEE (EMPCODE, EMPNAME, DEPTCODE)

VALUES ('EMP4', 'SUNIL KUMAR', 'PRODUCTION')

INSERT INTO DBO.EMPLOYEE (EMPCODE, EMPNAME, DEPTCODE)

VALUES ('EMP5', 'RAGHAVENDRA UPADHYA', 'TECHNOLOGY')

Now update “DEPTCODE” column for two rows.

--THIS UPDATE STATEMENT UPDATES DEPTCODE OF 'JOSEPH JEUNE'

--FROM ACCOUNTS TO PRODUCTION

UPDATE DBO.EMPLOYEE SET DEPTCODE = 'PRODUCTION' WHERE EMPCODE = 'EMP2'

--THIS UPDATE STATEMENT INSERTS NEW DEPTCODE IN SKTABLE

--AS 'HR' DOES NOT EXIST IN SKTABLE

UPDATE DBO.EMPLOYEE SET DEPTCODE = 'HR'

WHERE EMPCODE = 'EMP5'

Conclusion

Store Key concept has a broader usability with respect to reducing maintenance of many tables, primary keys, indexes in those tables and etc. The base idea that I though was creating a Store Room kind of repository for a database and store any kind of redundant data there, use it via SK ID wherever required. Rather than we writing some database objects for achieving Store Key concept, it would be better that MS SQL SERVER 2000 provide some inbuilt system functionalities for storing/manipulating Store Key Data. Please feel free to comment/criticise the article.

- Raghavendra Narayana

winzip iconDownload article

Note: Due to the size or complexity of this submission, the author has submitted it as a .zip file to shorten your download time. Afterdownloading it, you will need a program like Winzip to decompress it.

Virus note:All files are scanned once-a-day by Planet Source Code for viruses,but new viruses come out every day, so no prevention program can catch 100% of them.

FOR YOUR OWN SAFETY, PLEASE:
1)Re-scan downloaded files using your personal virus checker before using it.
2)NEVER, EVER run compiled files (.exe's, .ocx's, .dll's etc.)--only run source code.

If you don't have a virus scanner, you can get one at many places on the net including:McAfee.com

 
Terms of Agreement:   
By using this article, you agree to the following terms...   
1) You may use this article in your own programs (and may compile it into a program and distribute it in compiled format for languages that allow it) freely and with no charge.   
2) You MAY NOT redistribute this article (for example to a web site) without written permission from the original author. Failure to do so is a violation of copyright laws.   
3) You may link to this article from another website, but ONLY if it is not wrapped in a frame. 
4) You will abide by any additional copyright restrictions which the author may have placed in the article or article's description.


Other 9 submission(s) by this author

 

 
Report Bad Submission
Use this form to notify us if this entry should be deleted (i.e contains no code, is a virus, etc.).
Reason:
 
Your Vote!

What do you think of this article(in the Advanced category)?
(The article with your highest vote will win this month's coding contest!)
Excellent  Good  Average  Below Average  Poor See Voting Log
 
Other User Comments
8/27/2003 8:53:21 AM:
I see one major problem with this idea. Data Integrity. With one table that has all of these SKIDs in it, what is stop someone from using the the wrong SKID for the wrong column. That means that you would either have a lot of work to do in the triggers to combat this or you would have to let the programmers handle the data integrity on their end. While its a good idea for db size I try to stay away from catch all tables. I just don't think that they provide enough safety from bad data.
Keep the Planet clean! If this comment was disrespectful, please report it:
Reason:

 
8/28/2003 1:31:32 AM:Mark Kahn
not really a new concept...I've done this before. The only problem I've run into with the way you're doing it is that you can't store multiple data types. For a project I did recently, I ended up creating 6 different 'data' tables for different data types (varchar, int, datetime, etc). I suppose you could do the same thing with a bunch of cast statements, but the processing overhead would be huge.
Keep the Planet clean! If this comment was disrespectful, please report it:
Reason:

 
Add Your Feedback!
Note:Not only will your feedback be posted, but an email will be sent to the code's author in your name.

NOTICE: The author of this article has been kind enough to share it with you.  If you have a criticism, please state it politely or it will be deleted.

For feedback not related to this particular article, please click here.
 
Name:
Comment:

 

Categories | Articles and Tutorials | Advanced Search | Recommended Reading | Upload | Newest Code | Code of the Month | Code of the Day | All Time Hall of Fame | Coding Contest | Search for a job | Post a Job | Ask a Pro Discussion Forum | Live Chat | Feedback | Customize | SQL Home | Site Home | Other Sites | About the Site | Feedback | Link to the Site | Awards | Advertising | Privacy

Copyright© 1997 by Exhedra Solutions, Inc. All Rights Reserved.  By using this site you agree to its Terms and Conditions.  Planet Source Code (tm) and the phrase "Dream It. Code It" (tm) are trademarks of Exhedra Solutions, Inc.