On Wed, 2010-03-03 at 20:39 +0100, mk wrote: > Hello Tim, > > Pardon the questions but I haven't had the need to use denormalization > yet, so:
> IOW you basically merged the tables like follows? > > CREATE TABLE projects ( > client_id BIGINT NOT NULL, > project_id BIGINT NOT NULL, > cost INT, > date DATETIME, > INDEX(client_id, project_id, date) > ); Yup > From what you write further in the mail I conclude that you have not > eliminated the first table, just made table projects look like I wrote > above, right? (and used stored procedures to make sure that both tables > contain the relevant data for client_id and project_id columns in both > tables) Yup > Have you had some other joins on denormalized keys? i.e. in example how > the join of hypothetical TableB with projects on projects.client_id > behave with such big tables? (bc I assume that you obviously can't > denormalize absolutely everything, so this implies the need of doing > some joins on denormalized columns like client_id). For these joins (for SELECT statements) this _can_ end up running faster - of course all of this depends on what kind of queries you normally end up getting and the distribution of data in the indexes. I've never written anything that started out with a schema like this, but several have ended up getting denormalised as the projects have matured and query behaviour has been tested > > assuming you can access the first mapping anyway - > > ? I'm not clear on what you mean here. I'm refering to not eliminating the first table as you concluded > > Regards, > mk > -- http://mail.python.org/mailman/listinfo/python-list
