Hello everyone i am developing an accounts package for my company using Sql Server 2008 and VB.Net.
I need some help regarding the database design.
I have the following tables
AccountsGroupMaster
GroupId int
GroupName nvarchar(50)
ParentGroupId int
CatId int
PrimaryGroup bit
CreatedByUser nvarchar(50)
CreatedOn datetime
The above table will store the Groups for the accounts eg: Current Assets etc.
Accounts Table
AccCode nvarchar(6)
AccountName nvarchar(30)
ParentAcc nvarchar(6)
GroupId int
The above table stores the Accounts/Ledgers .
VoucherMain
VoucherNo bigint
VoucherDate datetime
DebitCredit int (0 for Credit 1 for Debit)
AccCode nvarchar(6) (Account Code to be debited/Credited)
UserID nvarchar(30)
VoucherDetails
VoucherNo bigint
SlNo int
AccCode nvarchar(6) (Debit this account if account in VoucherMain credited/ Credit this account if account in VoucherMain Debited)
Amount decimal(18, 2)
Narration nvarchar(MAX)
The above two tables store the transactions.The above two tables linked by the VoucherNo columns
Now my question is whether i should maintain all the bank accounts in the accounts table or should i have a separate table for the bank accounts.
As each bank account should have its respective ledgers.
Please help me in the design of this database.
thanks
Is a BankAccount different than an Account? If it's a different entity entirely then it would probably call for its own table. If it's just a certain kind of Account then it might not. In that case, there could be other options:
For example, you could add an AccountType to the Account table to determine which ones are BankAccount types and which ones are not.
Or, if the difference is more than just a type flag and includes additional Account-level columns of data which are applicable only to that specific type of Account instances, then you might make a sub-table. It would be a BankAccounts table, but its primary key would also be a foreign key to the Accounts table, creating an enforced 0-1 relationship between the two.
Then, whenever creating a BankAccount record you'd first add a record to the Accounts table, get the generated key, and use that key to add a record to the BankAccounts table.
Related
I'm trying to see if the Primary/Foreign keys can be used in the following way in MS SQL server 2012.
If I have two tables one with employer information and one with recruiter information.
If any given employer can have up to 5 recruiter accounts, then in my table each time a new recruiter account is created with the employer's PK ID in a matching column on the Recruiters table and have a matching field on the recruiters table that has a count of the # of recruiter accounts that exist in the recruiters table.
So
Employers Table = A
EmployerID int Unchecked
UserID int Checked
AccountStatus varchar(50) Checked
CompanyName varchar(150) Checked
JobsPosted int Checked
ResumeViews int Checked
ResumeFavorites int Checked
Recruiters int Checked
Recruiters Table = B
RecruiterID int Unchecked
EmployerID int Checked
UserID int Checked
AccountStatus varchar(50) Checked
JobsPosted int Checked
ResumeViews int Checked
ResumeFavorites int Checked
For each Recruiter that exists in table B auto-increment the value in Table A's Recruiters field.
Is that proper use of primary/foreign keys? Or should I be using TSQL to accomplish this?
I think you are missing the point of normalizing your database.
Let your employer data in the Employee and Recruiter data in the Recruiter and a EmployerRecruiterAccount table where 1 employer can have 5 recruiters.
So your EmployerRecruiterAccount will have EmployeeID and RecruiterID as foreign keys.
Take the following scenario:
CREATE TABLE customers (
cust_num INTEGER PRIMARY KEY,
cust_name VARCHAR(60) NOT NULL,
//other info
);
CREATE TABLE checking_account (
acc_num NUMBER(16) NOT NULL,
acc_type VARCHAR(8) NOT NULL,
//other info
);
CREATE TABLE savings_account (
acc_num NUMBER(16) NOT NULL,
acc_type VARCHAR(8) NOT NULL,
//other info
);
CREATE TABLE loan_account (
acc_num NUMBER(16) NOT NULL,
acc_type VARCHAR(8) NOT NULL,
//other info
);
CREATE TABLE has_account (
acc_num NUMBER(16) NOT NULL,
acc_type VARCHAR(8) NOT NULL,
cust_num INTEGER
);
More than one customer may have the same account and additionally, one customer may have multiple accounts. The account number in the has_account table may or may not be unique across accounts.
How could this be represented? I have tried to implement class table inheritance and concrete inheritance but I can't figure out how to allow one account number to be shared across multiple accounts. I have yet to find an example or explanation which makes this consideration. Could anybody give me an insight as to how to achieve this functionality or at least point me in the right direction? Any help is greatly appreciated
'customers' table is your primary table which should be linked with all 3 tables 'checking_account','savings_account' and 'loan_account'.In these 3 table there should be one column cust_num which will represent forign key.
So if customer has saving account and loan account then for this customer there is 2 row in customers table and one-one row in savings_account & loan_account table.
Customer all account info should be in has_account table where cust_num is forign key so you can easily find customer info with his account details via join on customer & has_account table.
If you want to know one customer has how many account then use count(cust_num) in your customers table.
Note - If you follow good DB design then you should have only one table called as 'cust_account' in which columns should be like acc_num,acc_code,acc_name etc and acc_type column should be updated with valid value like 'saving','loan' or 'checking'.
In your table structure acc_type column is given for all 3 account type tables which has no sense if you have different table for different account type.Remove this column if you are going to use seprate table for account type otherwise use one table with column acc_type.
Not a complete answer and too long for a comment but I thought I'd address some of your reasons why you have three separate tables:
"checking account doesn't have an interest rate"
This is a business rule and should not be implemented by a different table structure. Also, in times of higher interest rates it's certainly plausible for a checking account to earn interest. Business rules are usually much easier to change that data structures.
a loan account doesn't have a balance
Again, this is a business rule - but certainly a loan has a principle balance.
one account number may be shared across multiple account types ... account number would need to be a primary key in which case it couldn't be shared across accounts
One way to solve that is to use account number , account type as a "logical" compound primary key (note that in most DB systems there are benefits to using a sequence number as a "true" primary key that is independent of the actual record information. What if an account number changes for some reason?
If there are attributes of one account type that cannot feasibly stored in a "shared" data model, then you could model those as sub-tables:
|- 0:1 -- 0:1 CheckingAccount
Customer 1--* Account -|- 0:1 -- 0:1 SavingsAccount
|- 0:1 -- 0:1 LoanAccount
But you may find that you end up with similar problem that are more easily solved using business rules that separate data structures.
Create custReg table which have parent-child relationship of account types between column data. That column named accountID would be PK. As common attributes can easily be placed in single table.
Further tables with different attributes can be created and subsequently linked with theirs account ID at first-child level.
Then use hierarchical queries to access data between tables.
I am designing the database for an accounting system, currently working on the Expenses table.
According to IRS rules, whenever you update a row in any accounting table, you need to cancel out the existing row by negating its values, and create a new row with the modified information, like so:
Set the row's Status flag to "Modified"
Create an identical copy of this row, with all Money fields negated, so that the sum of the two rows is 0
Create a 3rd row, identical to the first one, with the modified data
Each expense has an identity field called ID for internal identification purposes, and an ExpenseID field, which identifies the transaction to the users. The two cannot be the same, because
ExpenseID can be repeated twice if the transaction was modified and its row was duplicated.
ExpenseIDs MUST be consecutive and NEVER have gaps, while identity fields can skip numbers if a transaction is rolled back and the identity is not reseeded.
In general, I believe the primary key should have no business meaning whatsoever.
My problem is that there are other tables used to link these expenses Many-To-Many to other objects in our system. E.g.: each expense can be linked to documents, folders, users, etc.
So it looks something like this:
create table Expenses (
ID int not null identity(1,1),
ExpenseID int not null,
Amount Money not null,
Status tinyint not null,
[...]
)
create table Expenses_Users (
ExpenseID int not null,
UserID int not null
)
alter table Expenses_Users add constraint FK_Expenses_Users_Expenses
foreign key (ExpenseID) references Expenses (ID)
alter table Expenses_Users add constraint FK_Expenses_Users_Users
foreign key (UserID) references Users (ID)
Now, because of the IRS guidelines, I have to duplicate not only rows in the Expenses table, but also in Expenses_Users, and any other table that links Expenses to other tables.
I have two ideas on how to solve this:
Option One: Normalize Expenses like this:
create table Expenses (
ID int not null identity(1,1),
ExpenseID int not null,
Status tinyint not null,
[...]
)
create table ExpensesNormalized (
ExpenseID int not null,
Amount Money not null
)
alter table ExpensesNormalized add constraint FK_ExpensesNormalized_Expenses
foreign key (ExpenseID) references Expenses(ExpenseID)
This means I'll only have to link external tables to Expenses, not ExpensesNormalized. Also, when updating an expense, I'll only duplicate and negate the data in ExpensesNormalized, which means I'll have far less redundant data in the Expenses table.
However, I'll have to use a JOIN clause every single time I SELECT from Expenses. I fear a performance hit because of this.
Option Two: Use the same tables I use now, but have the field Expenses_Users.ExpenseID point to the field Expenses.ExpenseID. This means that I won't have to duplicate any external objects because they'll point to ExpenseID, which may occur several times.
However, this will not be a real foreign key because SQL Server does not allow foreign keys to non-unique fields, so I'll have to implement foreign key logic in a trigger.
I'm having a hard time deciding between these two options. Any feedback would be appreciated.
I have a database which captures information relating to a patient for a medical practice. This information is spread across several tables:
Patient - For contact information
PatientMedicalHistory - For medical conditions unrelated to the current problem
PatientEpisode - Financial information for the current visit
PatientEpisodeReason - Stuff relating to why the patient is here today
I want to introduce a flag system, so that any messages will appear when bringing up the patient details. So for example, if the patient has had a heart attack previously this would need to be flagged (that info would be in PatientMedicalHistory).
My current approach is to set up a flag lookup table which defines the flag type, and the table/column that the flag is referring to and what the value would be in order to raise that flag:
CREATE TABLE FlagType
(
ID INT PRIMARY KEY IDENTITY,
TypeName NVARCHAR(300) NOT NULL,
Colour NVARCHAR(100) NOT NULL,
Urgency INT NOT NULL
)
CREATE TABLE Flag
(
ID INT PRIMARY KEY IDENTITY,
FlagTypeID INT NOT NULL REFERENCES FlagType(ID),
TableName NVARCHAR(300) NOT NULL,
FieldName NVARCHAR(300) NOT NULL,
FlagValue NVARCHAR(300) NOT NULL
)
This seemed all very well, but then trying to write either a) a stored procedure that doesn't resemble a mess or b) a LINQ query that doesn't kill performance seems difficult.
Is there any alternatives to this? The issue is that the flag could be defined on any column in any of the tables above. This totals about 80 columns in total.
You can add three fields to PatientMedicalHistory table: organ, disease, criticality.
When a patient comes in with a problem, you can pull patient history based on the same organ or disease presented in the current episode where the criticality meets a certain threshold. What you are doing here is classifying your patient history data so it relates to the current episode data.
I am working on a hotel management system in asp.net and I have a problem with designing the database.
I have something like this:
two types of Guests :family and company
each type can have many members and every member has attributes
the reservation is made by a guest
I think I need to make 3 tables:
Guest: guest id primary key, Guest name, Member ID foreign key
Members: Member ID primary key, Name, address, ...
Reservation: Reservation ID primary key, guest ID foreign key, ...
My problem is that I don't know how to make relation between tables.
For example the guest is company and he makes a reservation for 5 members,
but after a month he wants to make another reservation for 8 members.
What should I make so that I can make a reservation second time without being obligated to make another guest ID?
Seems like the schema doesn't need to be much more complex than this, unless you also need to show where certain guests get their own room, etc. As I mentioned in my comment, I don't think there is anything that dictates that every guest must be a member, in which case I would just wipe out ReservationGuests and re-populate when the reservation gets updated. Who wants to write logic that tries to guess which of the original guests are actually still on the list?
CREATE TABLE dbo.Members
(
MemberID INT PRIMARY KEY,
-- ... name, address, etc.
);
CREATE TABLE dbo.Reservations
(
ReservationID INT PRIMARY KEY,
MemberID INT FOREIGN KEY REFERENCES dbo.Members(MemberID),
... other attributes such as dates
);
CREATE TABLE dbo.ReservationGuests
(
ReservationID INT FOREIGN KEY REFERENCES dbo.Reservations(ReservationID),
GuestName NVARCHAR(255),
... other guest attributes
);
The problem is that you are assuming that the guest has members. It doesn't- as you mention, this week I might travel with my spouse, next week I might travel with the whole family, the week after that I might travel alone. The reservation has members, and the set of members might be different for each reservation. Hope that helps.
well u will need separate table for guests so for the 1st time they came to hotel u have to register that guest on your system. and as you said maybe he will come again after one month so just u have to search his SSN (Social Security Number). if he already register you don't have to register him again.
and your reservation table should be separate. and you should issue Reservation ID for each booking. so u can separately identify fields.
as example
A company came and resisted 1st time his registration number is "101" and that time his Reservation ID is "555"
after one month he will come again. and your system have option that check whether he is already resisted or not. well after system notice he already resisted and just make new Reservation ID for new booking
CREATE TABLE Member
(
Id INT IDENTITY (1,1) PRIMARY KEY,
Name VARCHAR(256),
Address VARCHAR(512),
MemberTypeId INT --FK to MemberType.Id
)
CREATE TABLE MemberType
(
Id INT IDENTITY(1,1) PRIMARY KEY,
TypeDescription VARCHAR(128)
)
CREATE TABLE Reservation
(
Id INT IDENTITY(1,1) PRIMARY KEY,
MemberId INT --FK to Member.Id
)
CREATE TABLE ReservationList
(
ReservationId INT, --FK to Reservation.Id
MemberId INT --FK to Member.Id
--Both of these values can act as a composite key
--At minimum, they should be unique as a pair
)
The above schema is how I would create the database based on your description. The Reservation table merely acts as an overarching reservation, and can be made by the company member without having to actually include the company member in the reservation (company makes reservation, but only for its employees). Then, the ReservationList is the list of all the members that will be tied to each reservation.
Hopefully this helps :)