in reply to Re^2: Design flat files database
in thread Design flat files database
From what you described, I get the impression an SQL optimisation book is not what you need. Rather, try out whether a variant (e.g. SQLite, PostgreSQL) would suit your needs better (i.e. more easily, less painfully) than flat files do.
I don't know the scale nor expected use of your project, so it's hard to advise. SQL isn't that hard, yet it's powerful.
- A friendship (ID) could have two user(ID)s as its members, for instance.
- Top rated items would be selecting an x count of items sorted by their rating values in descending order.
- Indexes are fairly standard too.
Optimising seems more for your flat files design, given that you have more experience there. Using a routine to generate paths from IDs (as suggested earlier) would be a good way to start a benchmark schemes vs filesystem flavour and operating loads you expect to see.