Question

嗯，这是一个小问题。

我要设计一个Web应用程序数据库，使用基本上是一种口语的语言。然而，这种语言有两个字母（拉丁语和西里尔语）和三个口语变体，实际上只有一些细微的差异（我认为有几百个单词略有不同）。为了使事情变得更加困难，数据库和管理界面将用于两个应用程序，其中一个将使用脚本和两个口头变体用于所有文章（以及界面），而其他应用程序将仅使用一个（拉丁文）。

我写了一个拉丁语到西里尔语和后面的“翻译”算法，这应该让用户更容易输入，但现在我面临一些我怀疑的数据库/应用程序规范化问题。

（1）我可以将此视为口语问题并相应地创建数据库。

| 'variant' | [id, name] #language variant
| 'article' | [id, <all variant non-dependent fields>] # such as image, relations, etc
| 'article_variant' | [id, fk_language_variant_id, fk_article_id, <all variant dependent fields>] #title, body, etc
| 'article_has_variants' | [id, fk_article_id, fk_article_variant_id]

然而，由于'article_variant'中的大多数数据库条目都包含相同的信息，这似乎是多余的。

（2）我可以使用'article'表和带有“latin-to-cyrillic-and-back”算法的单词对来显示它，以便在应用程序级别上向用户显示它。然后我的数据库看起来像这样：

| 'variant' | [id, name] #language variant
| 'article' | id, <all fields>
| 'words' | id, word
| 'word_pairs' | id, fk_word_id, fk_word_id

这个解决方案对我来说看起来很完美，但我担心它会对应用程序性能产生影响，因为事实上（a）每次在不同于每个单词的默认语言变体上显示它时，它必须通过整篇文章对和（b）之后它必须转换字母表中的每个字母（+由于复杂的字母转换，再多几次，如nj - >њ）到它的对。

有什么想法吗？

Answer 1

我将使用带缓存的动态选项。仅存储文章的一个变体（最初创建一个）并动态创建其他变体，如

 article = select from articles
 if article.lang != requested_lang
     text = select from cache where id=article.id and lang=requested_lang
     if !text
          text = convert_language(article.text, requested_lang)
          insert into cache(article.id, requested_lang, text
     echo text
 else
    echo article.text

（这意味着语言转换是完全自动的，我不确定是否是这种情况）

设计口语变体关系数据库的最佳实践

1 个答案: