Thread: database design
On 02/14/11 10:45 PM, Kalai R wrote: > hi, > > We are going to design database for a large company, which has many > branches. In each branch they maintain data separately and also they > maintain year wise data. ie > > Company > | > Branch > | > Yearly > > Also we need to compare and prepare reports by combine all branched data. > > How should we design the database. Please Give Guidance. hire an experienced IT department.
Hi Kalai,
From the vagueness of your question, it sounds like you need a DBA to design the database.
But basically you need to put the branch id as a foreign key in all data tables and then you can generate reports grouped by date or portion thereof, branch or company.
Sim
On 02/15/2011 08:45 AM, Kalai R wrote:
hi,We are going to design database for a large company, which has many branches. In each branch they maintain data separately and also they maintain year wise data. ieCompany|Branch|YearlyAlso we need to compare and prepare reports by combine all branched data.How should we design the database. Please Give Guidance.
Just curious; is it that you have never designed a multi-branch/company database before or do you have little or no database experience at all?
As mentioned, you want to tag these records with the branch primary key and relevant date or dates. The question still remains whether you are dealing with transaction/detail input data or whether you are being provided or will be creating (as part of an import routine) aggregate summaries that will have specific dates associated with an interval. If the later, what is the minimum interval (month, day, hour) that you want or need to store?
Also, do these branches have any sub-components (departments) that stand-alone and that also may want to be segregated and reported upon.
If none of the above makes sense then you will either need to:
invest time to read AND perform database design (and methods to get data into the database)
hire/retain someone to assist – and figure out what value-add “we” are bringing to the scenario (e.g., superior domain knowledge)
turn the project over to someone else and maybe get a finder’s fee and or recurring commission for the referral
If you do have database design experience and skills then dealing with multiple entities within a single table does not add that much complexity from a design standpoint. You are basically designing the core database to serve whatever function is needed but putting in hooks so you can define WHO that data belongs to. The number and kinds of levels is dependent upon the domain but it is generally safe to be too-fine since you can readily aggregate into less-fine groups but once you have a given level of fineness getting more-fine is difficult.
David J
From: pgsql-general-owner@postgresql.org [mailto:pgsql-general-owner@postgresql.org] On Behalf Of Kalai R
Sent: Tuesday, February 15, 2011 1:46 AM
To: pgsql-general@postgresql.org
Subject: [GENERAL] database design
hi,
We are going to design database for a large company, which has many branches. In each branch they maintain data separately and also they maintain year wise data. ie
Company
|
Branch
|
Yearly
Also we need to compare and prepare reports by combine all branched data.
How should we design the database. Please Give Guidance.