This is for the MS SQL Server development team that handles the code for Full Text Search. Hopefully you will read this. I developed a web application that supports multilingual content. As is typical in the real world, many people often need to create their
content in multiple languages or even have multiple languages present within the same content.
In my SQL Server database I have a single table that is used to store all the text from all languages. A single column is used to store this text. A separate column is used to identify the language of the content and uses Culture Codes like en-us, de-de,
etc.. Furthermore, the format of the content could be plain text, html or whatever. Business logic at a higher level in my application code knows what the format is for each record because data is retrieved within the context of whatever a web page uses. For
example, a user sending an e-mail would use plain text for the subject. For the body, html would be used. When these two pieces of information are stored in the same table, my code knows upon retrieving it what is text and what is html. It makes no sense storing
a subject and body of an email in two separate tables. This is just a simple example but hopefully you get the point.
After going through the documentation on FTS, it became clear to me that my table design is completely incompatible with the FTS paradigm. FTS requ
View Complete Post