SQLAlchemy, 多対多のテーブルデータ関連付け

Question

MySQL, SQLAlchemyで多対多のテーブルの関連付けを行なう場合、外部キー等を用いて、自動的に（？）データ同士が関連付けされる方法があるかと思いますが、以下のコードの様に、外部キー等の自動的に関連付けをせずに、中間テーブルを都度自分で作成し、利用する方法は問題あるでしょうか？　このプログラムによる方法でも実際に動作しますし、テスト段階では不都合を感じません。。
自動的な関連付けは便利な面も多いとは思いますが、「必要」では無い様に思うのですが、以下のコードの考え方では何か不具合が出てくるものでしょうか。また、自動的なrelationの設定による方法と、下記の様な手動での中間テーブルの設定の方法でのメリット、デメリットがあれば教えて下さい。

class Menu(Base):
    __tablename__ = 'menu_table'
    id = Column(Integer,primary_key=True, autoincrement=True)
    menu_name = Column(String(100),nullable=False)

class Zairyou(Base):
    __tablename__ = 'zairyou_table'
    id = Column(Integer,primary_key=True, autoincrement=True)
    zairyou_name = Column(String(100),nullable=False)

class MenuZairyou(Base):
    __tablename__ = 'menu_zairyou_relationtable'
    menu_id = Column(Integer, primary_key=True)
    zairyou_id = Column(Integer,primary_key=True)

def main():
    engine = create_engine('mysql+pymysql://{user}:{password}@{host}/{db_name}?charset=utf8'.format(**{
        'user' : "root",
        'password' : "password",  # localのMySQLはrootpasswordは無しにしてある
        'host' : "localhost",
        'db_name' : "relation_studydb"

    })
    )
    Base.metadata.create_all(engine)
    SessionMaker = sessionmaker(bind=engine)
    session = SessionMaker()

    # 初めにmenu_tableとzairyou_tableへの登録を行う
    new_menu = Menu(menu_name="ガパオライス")
    session.add(new_menu)
    new_zairyou = Zairyou(zairyou_name='鶏肉')
    session.add(new_zairyou)
    session.commit()
    # 登録した料理のidを準備
    register_menu = session.query(Menu).order_by(-Menu.id).first()
    
    # 材料のidを準備
    register_zairyou = session.query(Zairyou).order_by(-Zairyou.id).first()
    
    # menu_zairyou_relationtable への登録
    register_to_MenuZairyou = MenuZairyou(menu_id = register_menu.id, zairyou_id = register_zairyou.id)
    session.add(register_to_MenuZairyou)
    session.commit()

    # ２つの目の材料と登録
    new_zairyou = Zairyou(zairyou_name='バジル')
    session.add(new_zairyou)
    session.commit()
    register_zairyou = session.query(Zairyou).order_by(-Zairyou.id).first()
    
    # menu_zairyou_relationtable への登録
    register_to_MenuZairyou = MenuZairyou(menu_id = register_menu.id, zairyou_id = register_zairyou.id)
    session.add(register_to_MenuZairyou)
    session.commit()

if __name__ == '__main__':
    main()

Answer 1

「必要」では無い様に思うのですが

全く以てその通りです。

設定の方法でのメリット、デメリット

メリットはDBによってデータの整合性が保証される事、メニューデータのDELETEのみで済む事、
デメリットはメリットに書いた事の反対ですが、代わりに最初に大量のマスターデータを登録する時にはテーブル定義の通りに投入する必要が無いので、エクセルなどでマスターデータを登録する時に部分的なデータ投入のやり直しが簡単な事（これも後でondelete cascadeをつけてもいいが）

不整合の例としては、前の質問で言うメニューカレーのDELETE直後に不具合が起きた場合、カレーに紐づくmenu_zairyou_relationtableのデータが残る可能性があるという事です。
ondelete cascadeを使わない為にDELETEを二つのテーブルに対して発行しないといけないからこそ起きる不整合の可能性です。
但しその場合にじゃがいも料理のIDを中間テーブルから検索してカレーのIDが見つかったとしても、料理テーブルにそのIDが存在するかの確認をする設計なら問題は起きません。（いらないデータが残るだけ）
※新たにカレーを登録してもそれは別のIDが振られるのでID重複の不整合はありえない
そして上記の不整合もトランザクションを張ればプログラム側のみで解消出来る問題です。

DELETE直後の不具合とは、プログラムのエラーだったりDBのエラーだったり、DBとWEBが別サーバーにある場合はネットワークエラーだったり、色々考えられます。
でも自分の経験的にはondelete cascadeが無くても不都合はありません。

Comments

[sandalwalk]

ありがとうございます。
もう一つの質問でも状況を書かせて頂きましたが、ForeigKey, ondelete, back_populates, cascade等の全ての使い方を完全には理解出来ていません。これらの部分については、情報が圧倒的に少ないことに驚きました。また、色々調べると、私の様な初心者でなく、プロの方でも動作スピード等の点から素の中間テーブルで対応される方も居ると理解しました（正しいでしょうか？）
ただ学習中の身ですので、分からない所こそもう少し、本家の説明と照らし合わせながらプログラムをいじることを繰り返して、理解度を上げてからどのスタイルを利用するか考えようと思います。

[hentaiman]

> プロの方でも動作スピード等の点から素の中間テーブルで対応される方も居ると理解しました
動作スピードは関係ないです。
回答に書いた以外にも、on delete cascadeを使わずにプログラムで処理している場合はプログラムさえ読めばDBのデータの動きが読めます。
on delete cascadeを使って自動で中間テーブルを消す場合だと、プログラム読むだけだと中間テーブルが消えるところまでは読めないですよね？そういう混乱を防げます。
正しく制御さえ出来ていれば購入処理のある利用者数百万人規模のシステムでもそれで十分だと思ってます。（仕様書やマニュアル作成のコスパなども含めても）
個人的にDBによる整合性も保証されていて欲しいのは銀行のシステムですね。（銀行システム開発はやった事は無いけど）

> 本家の説明と照らし合わせながらプログラムをいじることを繰り返して、
先の質問のコメントにも書いたけど、まずは基本の通常の親子リレーションに慣れてからの応用がいいですね。その基本の為にはDBの基本的な部分の勉強が必要になりますが・・・

[hentaiman]

> 情報が圧倒的に少ないことに驚きました。
ドキュメントだけで十分だからでしょうね。実は自分はpython本格的に使って２～3週間程度でsqlalchemy（とalembic）を２～３日使った程度（で設定済んだので）ですけど内容的にはドキュメントで十分だと感じました。
自分も分からない事があった時にstackoverflowで検索して見つかったサンプルコードがありましたが、ドキュメントよく見たら同じサンプルコード載ってて説明も書いてあったので。

ただ情報を探しづらいドキュメントである事は間違いないです。stackoverflowで検索するにしても多少はsqlalchemyのソースを読みながら検索する必要はあると感じました。