多対多のリレーションの作成は可能でしょうか？
Javascriptによるコーディングをしないと難しいでしょうか？
多対多をシステムが用意していなくても、セオリーでは中間テーブルを作成し、１対N、N対１とするのではなにかうまくいかないことはありますでしょうか？
よろしくお願いいたします。
リレーションをちゃんとやりたい場合はJavaScriptカスタマイズは必須だと思います。
あくまで、kintoneはRDBMSではないので、正規化などの考えはそのままあてはめるのは難しいです。
（できなくもないが、JSでのカスタマイズは必要ですし、整合性の担保がとりづらかったり高コスト・冗長だったりする
下記が参考になりそうです。
村濱さま
参考ソースをご教示いただきありがとうございました。
ルックアップでは、外部キーでリンク付けられたデータへジャンプ参照するのであり、その他のフィールドへマスターからコピーしてくるような機能とはちょっと違う気がします。
すみません、教えていただきたいのですが、Javascriptで実装するところはどの部分なのでしょうか？
多対多をリストさせるwidgetが標準ではないので、それをJavascriptで作れるということであってますでしょうか？
（Javascriptで遜色なく実現できるのであれば、手間はかかれど制約にはならないので安心できます）
多対多を綺麗に表現できないのはけっこう致命的ですね。
標準widgetを用意してもらいたいものです。。。
たとえばAアプリとBアプリを他対他で紐付けるCアプリがあったとき、
CアプリにAアプリのIDとBアプリのIDをルックアップでもたせるようにすれば、JSを使わずとも一応他対他の表現自体はできると思います。
問題はその先で、Cアプリで紐付けられたAとBのアプリのデータを1回でひっぱりだすなど、テーブルのジョインができないんですよね。
JSでやらない場合はCアプリにAとBアプリの各フィールドのコピーをする必要がありますし（ただしその場合懸念としてAとBがアップデートされてもCがもっているデータはアップデートされない）、
JSでやる場合はAとBそれぞれからAPIを経由してデータを取ってくる必要がありますね
>すみません、教えていただきたいのですが、Javascriptで実装するところはどの部分なのでしょうか？
やりたいこと次第だとおもいます。どのように使いたいのでしょうか
村濱さま
非常にわかりやすく教えていただきありがとうございました。
バッチリとイメージができました。
やりたいことは、Aアプリのフォームの関連レコード一覧で、Bアプリの新規レコードを簡易登録する。
さらに、もっと詳細に登録するときは、関連レコード一覧でレコードの新規登録ボタン（アイコンか何か）をクリックすると、Bアプリの新規レコード登録フォームが表示され、登録が終了すると、Aアプリの画面に戻る。
という感じです。
よくあるUIです。
中間テーブルのCアプリのフォームから登録するのは避けたいです。
また、１対多の場合と同じで、よくできたUIはまず関連させたい登録済みの既存レコードがないか検索し、なければ新規登録させる、というスキームが最善です。
そのような複数アプリのデータを一回で操作したい場合はJavaScriptカスタマイズは必須ですね（基本的に、標準機能であれば触っているアプリだけしか値を変更できないとおもってもらっていいかと思います）
JS必須ではありますが、JSカスタマイズさえしてしまえば結構いろんなことができますので、拡張性・柔軟性についてはそこまで心配しなくてもいいと思います。
kintoneの弱点としては、さきに述べたようにRDBMSと違うのでそれを期待されるとちょっと違うのと、トランザクションに弱い部分がありますね。例えば、AアプリとBアプリのある値を同時に更新しようとしたとき、Aは成功したがBは失敗したときというのは、AもBももとに戻したいと思いますし、kintoneもそういう挙動（ロールバック）はできますが、その数が増えていくと全部は戻せません。10000件の件数を扱い、１件でもエラーが起これば全部なおす、ということは難しいです。（不可能とはいいませんが）
※下記APIなどを使えばロールバックができます
https://developer.cybozu.io/hc/ja/articles/201941814-複数アプリへのレコード一括処理
村濱さま
>JS必須ではありますが、JSカスタマイズさえしてしまえば結構いろんなことができますので、拡張性・柔軟性についてはそこまで心配しなくてもいいと思います。
なるほど安心しました。
>kintoneの弱点としては、さきに述べたようにRDBMSと違うのでそれを期待されるとちょっと違うのと、トランザクションに弱い部分がありますね。例えば、AアプリとBアプリのある値を同時に更新しようとしたとき、Aは成功したがBは失敗したときというのは、AもBももとに戻したいと思いますし、kintoneもそういう挙動（ロールバック）はできますが、その数が増えていくと全部は戻せません。10000件の件数を扱い、１件でもエラーが起これば全部なおす、ということは難しいです。（不可能とはいいませんが）
なるほどそのような問題もあるんですね。
アプリを複数まとめてパッケージできないのも不便ですね。中間テーブルを作ると１アプリとなるのかな。（笑）
まとめたり、アプリとして隠すみたいにできると便利なのですが。
すべて１テーブルが１アプリとする仕様を変えて欲しいと思います。
トランザクションとロールバックも含め、簡易DBという印象がぬぐえません（複雑な処理をカスタマイズしなければ）。
そうですね、繰り返しになってしまいますがRDBMSのようなリッチなDBとは違うことは念頭に置く必要があります。
> アプリを複数まとめてパッケージできない
パッケージ の言葉の定義によりますが、
アプリの書き出しができ、関連するものを一括でまとめることはできます。
https://faq.cybozu.info/alphascope/cybozu/web/kintone/Detail.aspx?id=1749&isCrawler=1
kintoneのメリットとしては、日頃業務でExcelなどで回していた部分をWeb化できるのが大きいです。データを蓄積して気軽に共有でき、更にコメントやプロセス管理もつけれるので、社員同士で業務を回すためのツールとしては大きな効果を発揮すると思います。
逆に向いてないのが、複雑なトランザクション処理を伴うものやデータの量がかなり多いもの、データの整合性を強く持ちたいものですね。複雑な基幹系システムなど。
コアな部分は既存の基幹系システムにまかせ、kintoneはAPI連携で組み合わせてつかう、ということもよくあると思います
村濱さま
的確な説明とアドバイスありがとうございます。
パッケージ化の意味ですが、
CRMでいうと取引先、担当者の１対多になっていることが多いです。
Kintoneの標準テンプレート顧客では担当者ごとに取引先（勤務先会社）を登録しますが、取引先として正規化して分割されていません。
顧客アプリをパッケージ化すると、そこに取引先アプリ、担当者アプリが含まれるイメージです。
また多対多の構築のため、中間テーブルを作成し、ご教示いただいた前述のようにJSなどで中間テーブル自体のフォームを使わないとき、中間テーブル自体を隠すということも必要かもしれません。中間テーブルアプリという意味のアプリは必要ありません。
パッケージに含めて管理するも、隠すということができるよ良いなと感じました。
このトピックはベストアンサーに選ばれた返信から 3 日が経過したので自動的にクローズされました。新たに返信することはできません。