- Visitors can check out the Forum FAQ by clicking this link. You have to register before you can post: click the REGISTER link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. View our Forum Privacy Policy.
- Want to receive the latest contracting news and advice straight to your inbox? Sign up to the ContractorUK newsletter here. Every sign up will also be entered into a draw to WIN £100 Amazon vouchers!
Reply to: DB/OO Design question
Collapse
You are not logged in or you do not have permission to access this page. This could be due to one of several reasons:
- You are not logged in. If you are already registered, fill in the form below to log in, or follow the "Sign Up" link to register a new account.
- You may not have sufficient privileges to access this page. Are you trying to edit someone else's post, access administrative features or some other privileged system?
- If you are trying to post, the administrator may have disabled your account, or it may be awaiting activation.
Logging in...
Previously on "DB/OO Design question"
Collapse
-
Surely there is only actually point in seperating the descriptions from the table rows if there is a many to one relationship? This may well be the case of course.
-
Originally posted by minestrone View PostJust thought I would see what peoples thoughts are on this...
*Thinks up example*
lets say you had a database/model with with 4 different tables/entities...
car boat plane train
And you add 0 or many String/varchar descriptions to each of them, would you have...
1. Description table/entity with 4 columns for the FKs and if it was for a car you would have the FK in a car column and the other 3 columns would be null.
Or would you have
2. 4 different tables/entitys CarDesc, BoatDesc etc.
The descriptions are just strings/varchars.
Code:CREATE table DescriptionType( DescriptionTypeID int not null PRIMARY KEY DescriptionEntity Varchar(50)--Car boat etc.. ) CREATE table Description( DescriptionID int not null DescriptionTypeID int not null Description VARCHAR(100) ) ALTER TABLE Decription ADD CONSTRAINT pk_primary_key PRIMARY KEY ON (DescriptionTypeID,DescriptionID) ALTER TABLE Decription ADD CONSTRAINT fk_foreign_key FOREIGN KEY ON (DescriptionTypeID) REFERENCES (DescriptionType.DescriptionTypeID)
Last edited by rsingh; 27 August 2010, 11:13.
Leave a comment:
-
Originally posted by minestrone View PostSee, I would go for 1 everytime (If the entities are a small and never changing group).
It's 1 table rather than 5, 1 class rather than 5. Simpler queries, faster access.
(Just came across 2 in here and it got me thinking)
The class model would have a base class with a subclass per type of entity.
This is assuming the entities are related in some way as per your example.
If it makes more sense to have a table per type of entity (i.e. not really related in any way) I would consider a single description table and use a composite foreign key of entity table + entity ID.
Leave a comment:
-
Originally posted by minestrone View PostJust thought I would see what peoples thoughts are on this...
*Thinks up example*
lets say you had a database/model with with 4 different tables/entities...
car boat plane train
And you add 0 or many String/varchar descriptions to each of them, would you have...
1. Description table/entity with 4 columns for the FKs and if it was for a car you would have the FK in a car column and the other 3 columns would be null.
Or would you have
2. 4 different tables/entitys CarDesc, BoatDesc etc.
The descriptions are just strings/varchars.
The description table would normally hold the primary key and the FK would be on any table linking to the description table.
You also don't say what the model is going to be used for(or if any changes to the design model are likely but we can ignore that for now)
If all the entity has is a text description of the entity then a single table model is preferred. Anything more complex then separate tables for each.
I agree whole heartedly to design as simple a model as the design constraints will allow for. I've seen some horrific examples of over complicated database designs (See my recent rant thread for a case in point)
Leave a comment:
-
See, I would go for 1 everytime (If the entities are a small and never changing group).
It's 1 table rather than 5, 1 class rather than 5. Simpler queries, faster access.
(Just came across 2 in here and it got me thinking)
Leave a comment:
-
I'd use a single table of the descriptions and just use the FK in each of your car boat place etc tables. easy peasy...as HAB has described.
Leave a comment:
-
OK, I’ll have a go because I am a self confessed non-techie and can make a fool of myself.
I’d have a separate table for the common fields that would map to the superior class and extra tables for those that were unique to the sub-classes. The PK of all of the sub tables would be the same as the superior one.
I do it in my DB and I get away with it.
Leave a comment:
-
DB/OO Design question
Just thought I would see what peoples thoughts are on this...
*Thinks up example*
lets say you had a database/model with with 4 different tables/entities...
car boat plane train
And you add 0 or many String/varchar descriptions to each of them, would you have...
1. Description table/entity with 4 columns for the FKs and if it was for a car you would have the FK in a car column and the other 3 columns would be null.
Or would you have
2. 4 different tables/entitys CarDesc, BoatDesc etc.
The descriptions are just strings/varchars.Tags: None
- Home
- News & Features
- First Timers
- IR35 / S660 / BN66
- Employee Benefit Trusts
- Agency Workers Regulations
- MSC Legislation
- Limited Companies
- Dividends
- Umbrella Company
- VAT / Flat Rate VAT
- Job News & Guides
- Money News & Guides
- Guide to Contracts
- Successful Contracting
- Contracting Overseas
- Contractor Calculators
- MVL
- Contractor Expenses
Advertisers
Contractor Services
CUK News
- Streamline Your Retirement with iSIPP: A Solution for Contractor Pensions Sep 1 09:13
- Making the most of pension lump sums: overview for contractors Sep 1 08:36
- Umbrella company tribunal cases are opening up; are your wages subject to unlawful deductions, too? Aug 31 08:38
- Contractors, relabelling 'labour' as 'services' to appear 'fully contracted out' won't dupe IR35 inspectors Aug 31 08:30
- How often does HMRC check tax returns? Aug 30 08:27
- Work-life balance as an IT contractor: 5 top tips from a tech recruiter Aug 30 08:20
- Autumn Statement 2023 tipped to prioritise mental health, in a boost for UK workplaces Aug 29 08:33
- Final reminder for contractors to respond to the umbrella consultation (closing today) Aug 29 08:09
- Top 5 most in demand cyber security contract roles Aug 25 08:38
- Changes to the right to request flexible working are incoming, but how will contractors be affected? Aug 24 08:25
Leave a comment: