Timeline for managing a growing database in the long run (10 years from now)
Current License: CC BY-SA 3.0
4 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Feb 28, 2013 at 14:58 | comment | added | Adrian Tanase | i see....this is my very ideea too, start prospecting on solutions, not just worrying about hdd space, db size etc. but I didn't know how to put it right in my question. I need to know before i launch the website if, at some point in the future, I can migrate to other optimised solutions, because site will build up and everything needs to be flexible in adapting to optimized solutions. thanks :) | |
| Feb 28, 2013 at 10:39 | comment | added | Chris Travers | I think the big thing is that it is important to become familiar with the sorts of solutions rather than worry about optimizing future problems away now. There's a good chance that in 10 years the problems you are facing are not the ones you thought you'd be facing then and solutions that complicate your code make it harder to solve new problems. I don't see anything wrong with what you are doing. | |
| Feb 28, 2013 at 10:29 | comment | added | Adrian Tanase | i considered using InnoDB for row-locking (not table). The site uses a lot of AJAX small updates (like the Like button on Facebook) and also not very frequent regular INSERTS, and a lot of READS. Pictures are being kept in the tree folder, and database is only text and numbers used to display stuff on the frontpage. I also have 2 separate admins, which will bring a lot of traffic and also the browsing through the stuff they define, on the frontpage which will bring a lot of reads on the httpd and mysql side. | |
| Feb 28, 2013 at 6:34 | history | answered | Chris Travers | CC BY-SA 3.0 |