Hi everybody, I'm working on a forum like web app where I record what topics have been read by a logged in user. Usually for a many-to-many relation like this, I would use a 3rd table, and have a user_id and a topic_id column in the table. I'm not sure if this is scalable in this case though, the table will meet three conditions:
It will be written to on almost most page views (to say the current topic has been read). It will be read from on most page views (to check which topics have been read and make this in the html). It may get very large (eg 1 million+ records). Usually, if a table is going to be this big and queried a lot, I will put an index on the columns that are queried. However, as well as being read from frequently, the table is also being written to frequently. As indexes take time to update on write, then updating the index constantly might end up slowing the table down so much that this method is not scalable. Does anyone know a way around this issue? Thanks. -- -- NZ PHP Users Group: http://groups.google.com/group/nzphpug To post, send email to [email protected] To unsubscribe, send email to [email protected] --- You received this message because you are subscribed to the Google Groups "NZ PHP Users Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
