SQLAlchemy, 多対多のテーブルデータ関連付け
解決済
回答 1
投稿
- 評価
- クリップ 0
- VIEW 303
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()
# 2つの目の材料と登録
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()
-
気になる質問をクリップする
クリップした質問は、後からいつでもマイページで確認できます。
またクリップした質問に回答があった際、通知やメールを受け取ることができます。
クリップを取り消します
-
良い質問の評価を上げる
以下のような質問は評価を上げましょう
- 質問内容が明確
- 自分も答えを知りたい
- 質問者以外のユーザにも役立つ
評価が高い質問は、TOPページの「注目」タブのフィードに表示されやすくなります。
質問の評価を上げたことを取り消します
-
評価を下げられる数の上限に達しました
評価を下げることができません
- 1日5回まで評価を下げられます
- 1日に1ユーザに対して2回まで評価を下げられます
質問の評価を下げる
teratailでは下記のような質問を「具体的に困っていることがない質問」、「サイトポリシーに違反する質問」と定義し、推奨していません。
- プログラミングに関係のない質問
- やってほしいことだけを記載した丸投げの質問
- 問題・課題が含まれていない質問
- 意図的に内容が抹消された質問
- 過去に投稿した質問と同じ内容の質問
- 広告と受け取られるような投稿
評価が下がると、TOPページの「アクティブ」「注目」タブのフィードに表示されにくくなります。
質問の評価を下げたことを取り消します
この機能は開放されていません
評価を下げる条件を満たしてません
質問の評価を下げる機能の利用条件
この機能を利用するためには、以下の事項を行う必要があります。
- 質問回答など一定の行動
-
メールアドレスの認証
メールアドレスの認証
-
質問評価に関するヘルプページの閲覧
質問評価に関するヘルプページの閲覧
checkベストアンサー
0
「必要」では無い様に思うのですが
全く以てその通りです。
設定の方法でのメリット、デメリット
メリットはDBによってデータの整合性が保証される事、メニューデータのDELETEのみで済む事、
デメリットはメリットに書いた事の反対ですが、代わりに最初に大量のマスターデータを登録する時にはテーブル定義の通りに投入する必要が無いので、エクセルなどでマスターデータを登録する時に部分的なデータ投入のやり直しが簡単な事(これも後でondelete cascadeをつけてもいいが)
不整合の例としては、前の質問で言うメニューカレーのDELETE直後に不具合が起きた場合、カレーに紐づくmenu_zairyou_relationtable
のデータが残る可能性があるという事です。
ondelete cascadeを使わない為にDELETEを二つのテーブルに対して発行しないといけないからこそ起きる不整合の可能性です。
但しその場合にじゃがいも料理のIDを中間テーブルから検索してカレーのIDが見つかったとしても、料理テーブルにそのIDが存在するかの確認をする設計なら問題は起きません。(いらないデータが残るだけ)
※新たにカレーを登録してもそれは別のIDが振られるのでID重複の不整合はありえない
そして上記の不整合もトランザクションを張ればプログラム側のみで解消出来る問題です。
DELETE直後の不具合とは、プログラムのエラーだったりDBのエラーだったり、DBとWEBが別サーバーにある場合はネットワークエラーだったり、色々考えられます。
でも自分の経験的にはondelete cascadeが無くても不都合はありません。
投稿
-
回答の評価を上げる
以下のような回答は評価を上げましょう
- 正しい回答
- わかりやすい回答
- ためになる回答
評価が高い回答ほどページの上位に表示されます。
-
回答の評価を下げる
下記のような回答は推奨されていません。
- 間違っている回答
- 質問の回答になっていない投稿
- スパムや攻撃的な表現を用いた投稿
評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。
15分調べてもわからないことは、teratailで質問しよう!
- ただいまの回答率 88.22%
- 質問をまとめることで、思考を整理して素早く解決
- テンプレート機能で、簡単に質問をまとめられる
2020/09/29 16:30
もう一つの質問でも状況を書かせて頂きましたが、ForeigKey, ondelete, back_populates, cascade等の全ての使い方を完全には理解出来ていません。これらの部分については、情報が圧倒的に少ないことに驚きました。また、色々調べると、私の様な初心者でなく、プロの方でも動作スピード等の点から素の中間テーブルで対応される方も居ると理解しました(正しいでしょうか?)
ただ学習中の身ですので、分からない所こそもう少し、本家の説明と照らし合わせながらプログラムをいじることを繰り返して、理解度を上げてからどのスタイルを利用するか考えようと思います。
2020/09/29 18:01
動作スピードは関係ないです。
回答に書いた以外にも、on delete cascadeを使わずにプログラムで処理している場合はプログラムさえ読めばDBのデータの動きが読めます。
on delete cascadeを使って自動で中間テーブルを消す場合だと、プログラム読むだけだと中間テーブルが消えるところまでは読めないですよね?そういう混乱を防げます。
正しく制御さえ出来ていれば購入処理のある利用者数百万人規模のシステムでもそれで十分だと思ってます。(仕様書やマニュアル作成のコスパなども含めても)
個人的にDBによる整合性も保証されていて欲しいのは銀行のシステムですね。(銀行システム開発はやった事は無いけど)
> 本家の説明と照らし合わせながらプログラムをいじることを繰り返して、
先の質問のコメントにも書いたけど、まずは基本の通常の親子リレーションに慣れてからの応用がいいですね。その基本の為にはDBの基本的な部分の勉強が必要になりますが・・・
2020/09/29 18:16 編集
ドキュメントだけで十分だからでしょうね。実は自分はpython本格的に使って2~3週間程度でsqlalchemy(とalembic)を2~3日使った程度(で設定済んだので)ですけど内容的にはドキュメントで十分だと感じました。
自分も分からない事があった時にstackoverflowで検索して見つかったサンプルコードがありましたが、ドキュメントよく見たら同じサンプルコード載ってて説明も書いてあったので。
ただ情報を探しづらいドキュメントである事は間違いないです。stackoverflowで検索するにしても多少はsqlalchemyのソースを読みながら検索する必要はあると感じました。