データベースを作成する.sqlファイルはどこに保存しますか？

Question

私は、ほとんどのアプリケーションと同様に、データベースを使用するWebアプリケーションを開発しようとしています。データベースを作成するには、データベースに加えたすべての変更が含まれている.sql -fileを書きます。なぜ正確にはわかりませんが、過去には、データベースを空にしたり、後で変更するのは難しいと感じました。私はまだこのデータベース関連のものすべてを学んでいるので、私のデータベースの最初のレイアウトは常に変更されます。これらすべての変更を追跡するために、この.sqlファイルを作成する習慣が増えました。

このファイルでは、常に既存のすべてのテーブルを削除して、すべてのテーブルを新規作成しています。私はデータベースの実際の状態をいつも手元に置いておくためにこれをやっています。ファイルの変更は、コマンドラインデータベースツールを直接使用するよりも簡単です。最初の質問は本当にあります：これは実際には良い練習ですか、私がまだ聞いていないことを整理する別の方法ですか？

実際の質問は次のとおりです。このファイルはどこに保存しますか？実際のコードと同じgitリポジトリに格納することをお勧めしますか？私は全くgitに入れておくべきでしょうか？私もgit/githubをクラウドストレージと考えています。ハードドライブが燃えると、私がgithubでそれらを手に入れて以来、私のプロジェクトはすべてそこに残ります。そこに.sqlファイルがない場合、私は新しいデータベースを設定する必要があります。

Answer 1

この種のコードの一般的なカテゴリは、「データベース移行」です。これらのタスクに特化したツールがあり、さまざまなWebアプリケーションフレームワークがさまざまな異なるDB移行ツールをサポートしている場合もあれば、独自の機能を持つ場合もあります。

Pythonのこのカテゴリの最も一般的なツール/スイート（SQLAlchemyで実装されているモデル）はAlembicです。その他のオプションには、Flyway,Liquibase、およびSqitchがあります。

これらのすべてのケースでは、データベーススキーマ（SQL、XML、YAML）の抽象概念を管理し、これらのツールは必要なSQLと他のコードを生成して、スキーマの各バージョンからあなたのプロジェクトの歴史通常、これらは増分として生成されます。最初のデータベーススキーマ（完全に空の場合もある）から始まり、そのバージョンにスキーマを構築して初期化します。作成して各ステップを実行して、目的のバージョンに到達します。

これは、スキーマをより根本的に変更する場合は、任意に複雑になる可能性があります。 「NOT NULL」制約なしでテーブルに余分な列を追加するのは簡単です。たとえば、「NOT NULL」ジャンクション・テーブルを使用して新しいM：Nリレーションシップを追加したり、一部の非正規化スキーマをより高い正規形に移行すると、いくつかの制約を削除して、過渡状態を通じて参照整合性違反を許容する必要がある中間段階が発生する可能性があります。

これらのツールがなぜ存在し、どのようにこの問題空間に近づくのかをより深く理解するために、これらのWebサイト、チュートリアル、HOWTO、その他のドキュメントを読むことを強くお勧めします。

Answer 2

Yuはホイールを再発明しています。私の友人、あなたのソリューションはDBスキーマをバージョン管理しています。そして、ほとんどのフレームワークのように、変更をプロジェクトファイルに追加する必要があります。次の質問をお読みになることをお勧めします。 How do you version your database schema?

Answer 3

はい、このコードは絶対にソース管理に入れてください。ただし、リポジトリ内のコードの正確な位置は、あなたや開発チームや管理者の責任で行ってください。いくつかの良いオプションは、インストール、セットアップ、SQL、またはddlフォルダです。

Answer 4

はい、あなたがしていることは正しいです。

ruby​​ on railsと比較：ファイルdb/schema.rbにはスキーマ全体が含まれています。このような完全なファイルもあります。これにより、たとえば、新しい環境（たとえば、新しいテスト環境）を簡単にブートストラップすることができます。このファイルは、すべてのデータを消去するため、本番環境では決して使用されません。

個別の小ファイルdb/migrations/20171003_add_name_to_person_table.rbなど、スキーマの段階的な変更 - マイグレーションと呼ばれるものがあります。これらは、データを失うことなく既存の環境を変更するために使用され、それぞれがDBごとに1回だけ実行されるようにするためのメカニズムがあります。

あなたのステージでは、このすべてを手動で行うのはまったく問題ありません。後で必要に応じて自動化を試みることができます。あなたが何かがここで起こっていることに気づいただけで十分です。

これは自然なところでは、コードリポジトリに移動する必要があります。 /db,/schema,/etcなどがあります。