Gagan Kr Sharma


Hello,friends

1) CustomerID

2) FirstName

3) MiddleName

4) SurName

5) Title

6) Marital Status

7) Education

8) Occupation

9) Annual Income

10) Line of Business

11) DOB

12) Father Name

13) Mother Name

14) SpouseName

15) Gender

16) Email

17) MainTel

18) Home Tel

19) Passport Number

20)----------------------

21)- - - - - - - - - - -

100)-------------------

Above mentioned list is a snapshot of our customer master table ,which contain approximately 100 attributes related to a customer.

We are designing an application for banking sector (but NOT Core banking solution),for which we may need to capture variable number of addresses for bank's customer,i.e more then three types of addresses Fixed,Temporary and Communication addresses(which is generally the case with all banks).

A single address includes address1/address2/city/country/state/pincode fields.

In context of OLTP database,We have option to put multiple addresses in child table but that involves various joins at the time of data retrival and slow down the query.

As another option we can can create redundent addresses columns(address1/address2/city/country/state/pincode) in master table that will accumulate addresses if demand for more then three type addresses arises(although there is reasonable numer of extra addresses is expected, i.e 10)

Database is expected to serve the records of 25 million(approx) bank's customer,so does someone can suggest me how to maintan the balance between two approches.





Re: OLTP Database Design help for bank's customer table

Jens K. Suessmeyer


If you cannot restrict the number of adresses possible you should use the parent - child approach. Data retrieval should be lateron no problem if the index strategy is designed well.

Jens K. Suessmeyer

---
http://www.sqlserver2005.de
---







Re: OLTP Database Design help for bank's customer table

richbrownesq

I agree with Jens.

Working with the parent-child relationship works well for extensibility and you should be able to get good performance with carefully considred indexes. It will be much easier to maintain and normalises your data.

I'll take a guess here and suggest that often you'll only be retrieving data based upon some form of customerID and this would appear to be an obvious key candidate which an index would benefit. With this, data retrieval speeds should be sufficiently fast though you'd obviously need to test this out.

eg

tblCustomer
CustomerID PRIMARY KEY,

Name,

DOB....

tblAddress

CustomerID PRIMARY KEY,

AddressType PRIMARY KEY,

Address1,

Town....

FOREIGN KEY tblAddress.CustomerID REFERENCES tblCustomer.CustomerID

HTH!!