2

（mysqlデータベース上で）、言語ごとに異なる変数を含むテーブルが必要です。たとえば、テキストの方向は、リンクなどをURLエンコードする必要がある場合は常に大文字の名前の最初の文字です。

人間はこれを次のように考えるでしょう：

id | lng | text direction | url encode | 1st letter cap |
---------------------------------------------------------
1  | en  | ltr            | 0          | 1              |
2  | he  | rtl            | 1          | 0              |
3  | fr  | ltr            | 1          | 1              |

しかし、このようにして、列を追加する必要があることに気付くかもしれません。これは、あまり優れたデータベース設計ではないことを理解しています。別のオプションは、「id」と「lng」の固定2列テーブルを維持し、次にこのテーブルを維持することです。

lng id | var            | val |
-------------------------------
1      | text direction | ltr |
1      | url encode     | 0   |
1      | 1st letter cap | 1   |
2      | text direction | rtl |
(and so on)

または、言語名とID、変数名とID、および上記の表の3つのテーブルでさえも可能です-変数テキストの説明を変数IDに置き換える場合。

var text descriptionの保存を忘れて、クエリを実行するときにids direcltyを使用することもできますが、これはあまり人間に優しいとは思えません。

どちらに行くのですか？

4

2 に答える 2

0

2番目の例は、属性値モデルを使用することです。（あなたが言ったように）頻繁に列を追加する必要がある場合、および/またはエンティティのほとんどがすべての列を必要とせず、そうでなければそれらを残す場合に役立ちますNULL。

欠点は、クエリの記述がより複雑になることです。そのため、可能な限りそれを避けようとします。たまに列を追加する必要があることを心配するよりも、単純さがより重要だと思います。新しい列を頻繁に追加する必要がない限り、たとえば、エンドユーザーが実行時に新しいフィールドを追加する必要がある場合は、最初のオプションを使用します。言語属性とその外部キーを含む言語テーブルです。それが必要。idおそらく列は必要ありませんlng。自然キーとして使用するだけです。

MongoDBのようなスキーマレスデータベースは、この問題をはるかにうまく処理します。列の概念がないため、いつでも新しいデータの保存を開始できます。すべてのフィールドを必要としないエンティティがある場合は、それらを指定しないでください。

于 2012-11-24T10:33:18.900 に答える
-1

JSON形式でエンコードしてみると、次のようになります。

id | value
------------------
1  | { "lng":"en" , "text direction":"ltr" , .... }

最小限の列が必要です

于 2012-11-24T09:03:33.180 に答える