''' + + ''' BETWEEN CAST(FLOOR(CAST(Room_DateFrom AS float)) AS datetime) AND Room_DateTo SET = CONVERT( datetime, = AS float)) AS datetime) Abrunden des Eingabedatums auf 00:00:00 Uhr This usually results in something like this (and it can't be used in views or table-valued functions by the way, which really is a problem if you actually need to filter the reporting date) CREATE PROCEDURE varchar(50) This naturally leads to using "dynamic SQL", so you don't have to alter all your queries. Which means you have to alter ALL your queries if you add a new language. In SQL (except PostGreSQL with hstore), you can't pass a parameter language, and say: SELECT ['DESCRIPTION_' + FROM T_Products Problem: You're denormalizing to save speed. This is an interesting issue, so let's necromance. There are pros and cons to each solution, and I would like to know what are your experiences with these approaches, what do you recommend and how would you go about designing a multilanguage database schema.
The translations table contains only a key, and a separate table contains a row for each translation to a language. Instead of storing translated text, only a foreign key to the translations table is stored.
Translation tables with rows for each language The translations table contains a column for each language. Translation table with columns for each language When we add a new language to the system, we must create additional columns to store the translated text, like this: CREATE TABLE T_PRODUCT (
I can think of three approaches to support multilingual text in NAME and DESCRIPTION columns: For instance one of the tables might hold product information: CREATE TABLE T_PRODUCT ( We can use language specific resources and have all kinds of tools that work well with them.īut what is the best approach in defining a multilanguage database schema? Let's say we have a lot of tables (100 or more), and each table can have multiple columns that can be localized (most of nvarchar columns should be localizable).
#Dbschema pro code#
As far as the application code goes, localizability is not an issue.
0 kommentar(er)
