テーブルを作成するとき、フィールドのリストを指定する必要があります。 テーブルで同じ名前のレコードを使用することは推奨事項に深く入りません。 mnesia：transform_table （フィールドの変換とテーブル定義の置換）を使用してドキュメントで提案されたオプションに従ってフィールドのリストを変更する場合、システムを停止し、テーブルを変換し、アプリケーションコードを変更して新しいタイプで動作し、テストを開始する必要があるようです。
SQLデータベースを見ると、フィールドの追加は基本的な操作です。
システム全体を停止することなく、新しいタイプに切り替えることが重要です。 少なくとも、データベースは継続的に機能する必要があります。
私はムネシアで読み書きを研究しました。 そして、結論はこれです：
Mnesiaは記録中にデータを厳密に制御します。 テーブル構造で宣言されているものだけを記述できます。それ以外の場合はエラーを記述できます。 レコードの名前と要素の数が制御されます-つまり すべて。
ただし、読み取り時に、Mnesiaは現在構成されているフィールドのリストとレコード名を確認せずに、書き込まれた内容を提供します。 また、フィールドのリストは、推奨されていないmnesia形式のtransform_table（Tab、 ignore 、Fildlist）を使用して、実際にレコードを変換することなく変更できます。
ドキュメントから判断すると、このフォームは、テーブルレコードのユーザー変換を目的としています。
すべてがどのように機能するかを見てみましょう。 たとえば、テーブルを作成し、データを書き込み、新しいフィールドを追加して、無視して変換します。
-module(recordtest).
-compile(export_all).
-record(r1 ,{f1,f2}).
-record(r2 ,{f1,f2,f3,f4}).
dbtest()->
mnesia:create_table(r1,[{attributes, record_info(fields, r1)}]).
transform()->
mnesia:transform_table(r1,ignore,record_info(fields, r2), r2).
テストします：
14> mnesia:create_schema([node()]).
18> mnesia:start().
ok
19> recordtest:dbtest().
{atomic,ok}
20> mnesia:dirty_write(r1, {r1,l1,l2}).
ok
21> mnesia:dirty_write(r1, {r1,t1,t2,t3}).
** exception exit: {aborted,{bad_type,{r1,t1,t2,t3}}}
in function mnesia:abort/1
22> mnesia:dirty_write(r1, {r2,l1,l2}).
** exception exit: {aborted,{bad_type,{r2,l1,l2}}}
in function mnesia:abort/1
23> mnesia:dirty_read(r1, l1).
[{r1,l1,l2}]
24> mnesia:dirty_read(r1, l1).
[{r1,l1,l2}]
38> recordtest:transform().
{atomic,ok}
39> mnesia:dirty_read(r1, l1).
[{r1,l1,l2}]
40> mnesia:dirty_write(r1, {r2,l1,l2}).
** exception exit: {aborted,{bad_type,{r2,l1,l2}}}
in function mnesia:abort/1
41> mnesia:dirty_write(r1, {r2,a1,a2,a3,a4}).
ok
49> mnesia:dirty_read(r1, l1).
[{r1,l1,l2}]
50> mnesia:dirty_read(r1, a1).
[{r2,a1,a2,a3,a4}]
これで、テーブルに両方のタイプのレコードがあり、それらを読み取ることができます。 しかし、
mnesia:add_table_index(r1,[l4]).
レコードの4番目のフィールドにインデックスを作成しようとすると、
mnesia:add_table_index(r1,[l4]).
-致命的なエラーを取得し、mnesiaを停止します。 次回このデータベースを起動すると、エラーが再び発生します。 r1.dcmファイルを削除すると役立ちます。その後、mnesiaが起動します。 また、スキーマからテーブル定義を削除する必要があります。
したがって、テーブル内のすべてのレコードがインデックスの仕様に準拠していない限り、インデックスを作成する必要はありません。
上記のすべてに基づいて、それは議論することができます-健忘症テーブルの変換は非常に深刻な問題です。 どうやら、設計段階で、テーブルを変換するためのシステムの動作モードを提供する必要があります。
また、新しいタイプまたは古いタイプのレコードがテーブルに配置されるときに、移行モードで機能する可能性を示します。 新しいタイプのレコードへの移行を完了する（古いタイプのレコードを削除する）方法は、特定のシステムによって異なります。
誰かがMnesiaのテーブルを変更する問題に慣れているなら、それを共有してください。 Mnesiaに関する情報はほとんどありません。