I agree with Tom. With the proper indexes a single table for all languages is the way to go.
I don't think a view for each language is necessary--just make a function that takes language and whatever you use to look up the localized strings, and returns the localized string. Further, there are existing frameworks that do this sort of task fairly well for several architectures. Not that there's anything wrong with building you're own--but you might look at some of their design to get ideas. Various: http://www.gnu.org/software/gettext/manual/gettext.html Qt C++: http://doc.trolltech.com/4.5/linguist-manual.html Java: http://java.sun.com/developer/technicalArticles/Intl/ResourceBundles/ Wes > If you are wanting to dynamically change the CurrentLanguage view in > everyday ongoing use, then you probably shouldn't. It's not generally > good to adjust the schema continually (ie drop and create a table or > view etc). You'd be better to redesign your data so that it's all in > one table, with the addition of a "Language" column. Then you can > select the data you want for a particular language without adjusting > your schema, such as: > > select * from AllLanguages where Language = 'English'; > > or you could create a view, once, for each language, that refers to > the one conglomerate table: > > create view "English Language" as select * from AllLanguages where > Language = 'English'; > > Tom > BareFeet _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
