StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
primarykey
Id
6708686
data
AcceptedAnswerId
0
AnswerCount
0
ClosedDate
CommentCount
0
CommunityOwnedDate
CreationDate
2011-07-15T14:35:38.607
FavoriteCount
0
LastActivityDate
2011-07-15T14:35:38.607
LastEditDate
LastEditorUserId
0
OwnerUserId
844771
ParentId
6608603
PostTypeId
2
Score
3
ViewCount
0
LastEditorDisplayName
text
Body
You should do both - maintain a master storage of the language data in a database, which will make it easy to build management application around it, and build local files (or other local storage approach) for the actual execution. Constantly querying language data from the database is wasted effort, specifically because language data typically is pretty static. If you want to ensure scalability, you should build on at least three layers: <ol> <li>Local (<a href="http://www.sqlite.org/" rel="nofollow">SQLite</a>, <a href="http://redis.io/" rel="nofollow">Redis</a>, files in <a href="http://en.wikipedia.org/wiki/Tmpfs" rel="nofollow">tmpfs</a>...); and</li> <li>Cloud-like (e.g. <a href="http://memcached.org/" rel="nofollow">Memcached</a>); and </li> <li>Master storage (e.g. a database server)</li> </ol> The decision on which layer to store your data should always be based on from where the data is retrieved in the most efficient way: <ol> <li>Static or de facto static data (=language, configuration, skins...) should be stored locally, to guarantee fastest possible access to the data. You will have to come up with a way for building and syncing updated data across multiple servers (save for local cache, if you are using such). Approaches include: <a href="http://en.wikipedia.org/wiki/Rsync" rel="nofollow">rsync</a>, <a href="http://www.cis.upenn.edu/~bcpierce/unison/" rel="nofollow">unison</a>, Redis replication, version control systems...</li> <li>Dynamic but cacheable data should live in the cloud-like cache, as the assumption is that it is often rebuilt and so can take advantage of the performance gains that come from sharing built data.</li> <li>Database should be only accessed when you can't avoid it (e.g. stale cache)</li> </ol> I wouldn't particularly worry about the IO access costs. Scaling a database server or having to do rearchitecturing mid-project will be much more expensive than the IO. And if you're worried about it, find a local storage solution that mainly relies on RAM and you can avoid the disk reads altogether and enjoy another performance gain.
Tags
Title
singulars
PostAcceptedAnswerId
1. This table or related slice is empty.
PostParentId
1. POWhere to store translations in cloud applications?
 singulars
 PostTypePostTypeId
 PTQuestion
PostTypePostTypeId
1. PTAnswer
UserLastEditorUserId
1. This table or related slice is empty.
UserOwnerUserId
1. USAleksi Asikainen
plurals
PostLinksPostIdRelatedPostId
1. This table or related slice is empty.
PostLinksRelatedPostIdPostId
1. This table or related slice is empty.
PostsAcceptedAnswerId
1. This table or related slice is empty.
PostsParentIdCreationDate
1. This table or related slice is empty.
VotesPostIdCreationDate
1. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
CommentsPostId
1. This table or related slice is empty.

Querying!

Guidance

A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.