12

Mnesiaを理解するための私の探求において、私はまだリレーショナル用語で考えることに苦労しています。だから私はここに私の闘争を置き、それらを解決するための最良の方法を求めます。

1対多の関係 私にはたくさんの人がいると言ってください、

-record(contact, {name, phone}).

今、私は電話を常にリストとして保存するように定義できることを知っているので、人々は複数の電話番号を持つことができます、そしてそれがそれを行う方法だと思います（そうですか？それでは、これを逆に調べるにはどうすればよいですか？たとえば、番号の名前を見つけますか？）。

多対多の関係 では、人を入れることができる複数のグループがあると仮定しましょう。グループ名には意味がなく、単なる名前です。概念は「unixシステムグループ」または「ラベル」です。素朴に、私はこのメンバーシップをプロップリストとしてモデル化します。

{groups [{friends, bool()}, {family, bool()}, {work, bool()}]} %% and so on...

たとえば、上からの「連絡先」レコード内のフィールドとして。グループ名に基づいてグループのすべてのメンバーをすばやく検索できるようにし、個人が登録されているすべてのグループを検索できるようにする場合、mnesia内でこれをモデル化するための最良の方法は何ですか？もちろん、これをグループ識別子だけを含むリストとしてモデル化することもできます。mnesiaで使用する場合、これをモデル化するための最良の方法は何ですか？

この質問がばかげている場合はお詫び申し上げます。mnesiaに関するドキュメントはたくさんありますが、全体的な使用法の良い例がいくつか欠けています（IMO）。

4

2 に答える 2

3

最初の例では、次のレコードについて考えてみます。

-record(contact, {name, [phonenumber, phonenumber, ...]}).

contactは2つのフィールドを持つレコードでnameありphone、phoneは電話番号のリストです。user425720が言ったように、たとえば、小さなストレージフットプリントが極端に必要な場合は、これらを文字列以外のものとして保存するのが理にかなっています。

ここで、Key-Valueストアで「取得」するのが難しい部分があります。逆の関係も保存する必要があります。つまり、次のようなものが必要です。

-record(phone, {phonenumber, contactname}).

アプリケーションにデータベース処理を抽象化するレイヤーがある場合は、連絡先を追加/変更するときに、常に電話レコードを追加/変更することができます。

-

2番目の例では、次の2つのレコードについて考えてみます。

-record(contact, {uuid, name, [group_id, group_id]}).
-record(group, {uuid, name, [contact_id, contact_id]}).

最も簡単な方法は、関連するレコードを指すIDを保存することです。Mnesiaには参照整合性の概念がないため、たとえば、すべてのユーザーからそのグループを削除せずにグループを削除すると、これが同期しなくなる可能性があります。

グループのタイプを連絡先レコードに保存する必要がある場合は、次を使用できます。

-record(contact, {name, [{family, [group_id, group_id]}, {work, [..]}]}).

-

2番目の問題は、「メンバーシップ」と考えることができる中間レコードを使用することによっても解決できます。

-record(contact, {uuid, name, ...}).
-record(group, {uuid, name, ...}).
-record(membership, {contact_uuid, group_uuid}). # must use 'bag' table type

「メンバーシップ」レコードはいくつでも存在できます。ユーザーグループごとに1つのレコードがあります。

于 2010-11-24T07:36:27.277 に答える
-1

まず、Key-Valueストアの設計パターンを求めます。完全に元気です。私があなたの質問に答えようとする前に、それを明確にしましょう-Mnesiaとは何ですか。OTPに含まれているのはkvDBです。ネイティブなので、Erlangからの使用は非常に快適です。ただし、注意してください。これは非常に古い仮定を持つ古いデータベースです（たとえば、線形ハッシュを使用したデータ分散）。ですから、先に進んで、それを学び、試してみてください。ただし、本番環境では、時間をかけてNoSQLショップを閲覧し、ニーズに最適なものを見つけてください。

@telephoneの例。ものを文字列として保存しないでください（list（））-GCにとっては非常に重いです。phone_1 :: << binary >>、phone_2 :: << binary >>、phone_extra :: [<< binary >>]のようなカップルフィールドを作成し、最も頻繁なクエリフィールドにインデックスを作成します。また、記憶喪失の指標には注意が必要です。ノードがクラッシュして起動すると、ノードを再構築する必要があります（非常に時間がかかる場合があります）。

@familyの例。フラットな名前空間ではかなり難しいです。より複雑なキーで遊ぶことができます。多分、TheGroup用に別のテーブルを作成し、メンバーの識別子を保持しますか？または、各メンバーは自分が属するグループのIDを持っています（維持するのは難しいです..）。友人を認識したい場合は、データを提示する前に何らかの契約を実装します（BがAの友人である場合、AはBの友人です）。このアプローチは、結果整合性とデータの競合に対処します。

于 2010-11-06T23:13:57.893 に答える