java - Multilanguage BBD Scheme -

i thinking create database of books (books formed 1 or 2 images , texts , numbers). want make data available in multilanguage (multi5-eur start) , quantity of items 27000 (25000 translated approximatelly)

reading little, see lot of disccording ways create this, interesting idea found this:

• one unique table books , various tables each translatable text (text, description.. references id each language, example) make mi books table big.

books id | title_es | title_en | .. 

• one unique table common data (non translatable) , "metadata" table, relation culture table. (culture table have relations genres, editions_name..)

books ----------- id | edition_id | date | author | genre_id | metadata_id |...  metadata ----------- id | title | description | summary | culture_id ...  cultures --------- id | culture 

the idea these books have lot of properties can use search (author, editorial, isbn, date, sells, ..) , i want make efficiently possible.

i hope start instructive disscussion topics, speaking 30k of registers, grow 500 per year aprox.. there arent big quantity of data, no?

as mention liferay in tags, you've omitted option: utilizing servicebuilder can translate individual columns declaring them translatable. result stored xml in respective database columns - send shivers down spine of database normalization guy. however, it's not bad:

thinking of database reports storage done way typically sucks: reporting tools don't know how extract correct language xml content. however, dealing classic reports on translated key-value pairs foreign key relationships sucks well. reports won't easy write , quite bad in maintenance. foresee you'll use classic reporting tools? factor decision.

you mention "as efficient possible". what's efficiency? efficient write software? servicebuilder wins. efficient maintain software? servicebuilder wins. efficient filter translated name? database filtering mechanism non-xml content win. looking titles in full text index? (you have tagged lucene in question): doesn't make difference how data stored.

after these thoughts there no correct answer question , causes opinionated discussions - bad fit stackoverflow based on criteria questions here. anyway, hope helps, i'd rather expect question closed due discussion character.

ask db-centric opinions , you'll normalization thrown @ you. ask software centric opinions , try maximize maintainability of written code. pick situation find in , go result.