I mean to say that we can maintain a single table , rather than scatering the data across tables,
Joined: Dec 28, 2006
This depends on the logic and how you want to combine your data with the tables. If you use an ORM-solution it could be logical that an object equals an table. I nowadays just follow this approach for simplicity and understanding. Over a few years when I have to rewrite my code I want to simply understand it.
I have experienced that most databases don't have a lot of performance problems joining different tables if you carefully use your indexes. Also mostly within forms and applications you just need some records and not all the records within a table.
Lately I was by a customer and just creating and using indexes solved a lot of performance problems.
We are in the performance forum. So is there a performance problem with the joins?
Ravi Kiran V wrote:I mean to say that we can maintain a single table , rather than scatering the data across tables,
Data integrity. if you modelled a nullabel one-to-one relationship in a single table its only a matter of time before some applciaiton logic messes the data up. If you have non-nullable fields in a joined table but the relationship is optional your data is safer.
With modern databases, you do need to ramp up the joins to start to hit performance issue and you will know better than us if your application will frequently have to join multiple tables. If you have issues, indices will fix many and denormalizing part of the data will fix more. But I'd hesitate to go straight to denormilzation.