問題タブ [database-versioning]

ゴール

1. CREATE TEMPORARY TABLEネイティブ SQL を使用せずに Hibernateでステートメントを呼び出します。つまり、HQL または Hibernate API のみを使用します。
2. オブジェクトを一時テーブルに保存します。
3. 既存のテーブルと一時テーブルを利用するストアド プロシージャを呼び出します。
4. DROP終了時の一時テーブル。（必須ではないことはわかっていますが、そうするのは良い習慣だと思います。）

バックグラウンド

1. 私は SQL に精通していますが、Hibernate は初めてです。
2. プロジェクトで Hibernate を使用せざるを得なくなったのは、誰かの決定が原因です。
3. Web フォームを Oracle データベースに保存します。
4. Web フォームには、各セルに 1 つずつテキスト フィールド (他の人が設計したもの) でいっぱいのテーブルが含まれています。
5. ユーザーが をクリックしたときSave、値は単一のトランザクションで保存する必要があります。
6. Web フォームは、データベース ビューによってバックアップされます。
7. データベース ビューは、EAV パターンを使用してデータベース テーブルから作成されます。(これは、列が何らかの形で動的であるためです。)
8. Web フォームの各テキスト フィールドは、データベース テーブルの 1 つの行によってモデル化されます。
9. Web フォームを表示するSELECTには、ビューでステートメントを使用します。
10. Web フォームの更新では、ビューのトリガーUPDATEを呼び出すビューのステートメントを使用します。INSTEAD OF
11. 変更された値のみが更新されます。更新ごとに監査証跡があります。
12. ユーザーの通知なしに別のユーザーによっていずれかの値が更新された場合、トランザクションはロールバックされます。このようなシナリオの例を次に示します。ユーザーが Web フォームを表示すると、別のユーザーが同じフィールドを更新し、最初のユーザーがフィールドを更新して Web フォームを送信したとき(I)の値が aになります。4(II)5 (III)2

当初提案されたソリューション

1. AJAX (jQuery) を使用してテキスト フィールドの変更を検出し、ユーザーが変更したものだけを送信します。
2. ただし、別のユーザーによる変更は、データベースで検出する必要があります。

より適切に機能するはずのソリューション

1. ユーザーが をクリックSaveすると、一時テーブルが作成され (一時テーブルは現在のセッション/接続でのみ表示されるテーブルであり、セッションが閉じられるか切断されると自動的に削除されます)、オブジェクト (セル) を一時テーブルに保存します。
2. 取引を開始します。
3. 既存のテーブルの一部をロックします (パフォーマンスのために、関連する行のみをロックします)。
4. 提出されたデータを既存のデータと比較します。
5. 気付かない変更が行われた場合は、トランザクションをロールバックします。
6. 必要な行を更新します。
7. トランザクションをコミットし、テーブルのロックを解除します。
8. 一時テーブルをドロップします。

何かアイデアはありますか？

これは、すべての人が別々のデータベースを持っている開発者のチームで開発している人たちへの質問です。ソース管理やその他のツールを使用してデータベースをバージョン管理しているため、開発データベースはデータベースの最新バージョン（スキーマ、データ、SP、関数など）に自動的に更新されます。

OK素晴らしい！ちょっと待って！ソフトウェアのバージョン4.0で開発しているが、バグを修正するためにブランチを3.2ブランチに切り替える必要がある場合はどうなりますか？スキーマは（ほぼ確実に）今では非常に異なっている可能性があります...

変更スクリプトと一緒にロールバックスクリプトを作成するために余分な労力を費やした場合、これは機能する可能性があると思います。しかし、それは大変な作業のように思えます-それは本当に価値がありますか？

私たちのプロジェクトには、いくつかの本番データベースと多くの開発者がいます。各本番データベースは、いくつかの「サブプロジェクト/ローカリゼーションバージョン」を表します。SQLServer2008を使用しています。

したがって、MSVisualStudioデータベースプロジェクトを使用してデータベースのバージョン管理戦略を開発する必要があります。データベースのバージョニングとデータベースプロジェクトに関する多くの記事を読みましたが、まだ多くの質問があります。

1. 開発者はdbプロジェクトへの変更をどのように実装する必要がありますか？（ベストプラクティス）

2. 人間の介入（一部のオブジェクトのスキップ、一部の変更の書き換えなど）なしで、100％実行可能な「最新バージョン」のデプロイスクリプトを生成するにはどうすればよいですか？

3. MS Visual Studioデータベースプロジェクトでデータの変更を管理するにはどうすればよいですか？デプロイ前/デプロイ後のスクリプトについては知っていますが、この問題を解決できないと思います。（例：あるテーブルを別のテーブルに再マップする必要があります）。

「理想的な解決策」は次のとおりです。

1. 開発者は、データベース[ProductionDB]のデータベースプロジェクトを生成および保守します。

2. 新しいリリースでは、必要なすべての変更を加えて、データベースプロジェクトを[ProductionDB]にデプロイします。

3. 開発者はデータベースプロジェクトを変更し、具体的な変更のためにいくつかのデータ操作スクリプトを作成します。

4. 新しいリリースでは、必要なすべての変更を加えて、データベースプロジェクトを[ProductionDB]にデプロイします。

それで、最後の質問：上記の目的でデータベースプロジェクトを使用することは可能ですか、それとも誰かが同様のシナリオ/ソリューションを使用しますか？

PS：私はすでに次の議論を読みました：

1. データベースのバージョン変更のバージョン管理[クローズ]
2. MS SQLデータベースをSVNでバージョン管理するにはどうすればよいですか？
3. データベースのバージョン管理のためのソリューションを探しています
4. データベース構造変更のためのバージョン管理システムはありますか？

Cassandraでデータバージョニングをどのように実装するかについての考えを共有できますか？

単純な名簿のレコードをバージョン管理する必要があるとします。（名簿レコードは、ColumnFamilyに行として保存されます）。私はその歴史を期待しています：

• 使用頻度は低くなります
• 「タイムマシン」方式でそれを提示するために一度に使用されます
• 1つのレコードに対して数百を超えるバージョンはありません。
• 履歴は期限切れになりません。

私は次のアプローチを検討しています：

• アドレス帳をスーパーカラムファミリに変換し、複数のバージョンのアドレス帳レコードをスーパーカラムとして（タイムスタンプで）キー設定された1つの行に保存します。

• 新しいスーパーカラムファミリを作成して、古いレコードまたはレコードへの変更を保存します。このような構造は次のようになります。

  {'名簿行キー'：{'タイムスタンプ1'：{'名'：'新しい名前'、'変更者'：'ユーザーID'、}、

  '別の名簿行キー'：{'タイムスタンプ'：{...。

• 新しいColumnFamillyに添付されたシリアル化された（JSON）オブジェクトとしてバージョンを保存します。バージョンのセットを行として、バージョンを列として表します。（ CouchDBを使用した単純なドキュメントのバージョン管理をモデルにしています）

MongoDB でデータのバージョン管理をどのように実装しますか? （Cassandra に関して同様の質問をしました。どのデータベースが適しているか考えている場合は、共有してください）

単純なアドレス帳のレコードをバージョン管理する必要があるとします。(アドレス帳レコードはフラットな json オブジェクトとして保存されます)。私は歴史を期待しています：

• まれに使用されます
• 「タイムマシン」のように一度に表示するために使用されます
• 1 つのレコードに数百以上のバージョンが存在することはありません。履歴は失効しません。

私は次のアプローチを検討しています：

• レコードの履歴またはレコードへの変更を格納する新しいオブジェクト コレクションを作成します。アドレス帳エントリへの参照とともに、バージョンごとに 1 つのオブジェクトを格納します。このようなレコードは次のようになります。

  このアプローチは、ドキュメントごとにバージョンの配列を格納するように変更できます。しかし、これは利点のない遅いアプローチのようです。

• アドレス帳のエントリに添付されたシリアライズ (JSON) オブジェクトとしてバージョンを保存します。そのようなオブジェクトを MongoDB ドキュメントに添付する方法がわかりません。おそらく文字列の配列として。( CouchDB を使用した単純なドキュメントのバージョン管理をモデルにしています )

PostgreSQLでデータバージョニングをどのように実装するかについての考えを共有できますか？（ CassandraとMongoDBに関して同様の質問をしました。どのデータベースがそのために優れているかについて何か考えがあれば、共有してください）

単純な名簿のレコードをバージョン管理する必要があるとします。名簿のレコードは、簡単にするために関係なしで1つのテーブルに格納されます。私はその歴史を期待しています：

• 使用頻度は低くなります
• 「タイムマシン」方式でそれを提示するために一度に使用されます
• 1つのレコードに対して数百を超えるバージョンはありません。
• 履歴は期限切れになりません。

私は次のアプローチを検討しています。

• アドレス帳テーブルのスキーマのコピーを使用してレコードの履歴を格納する新しいオブジェクトテーブルを作成し、アドレス帳テーブルにタイムスタンプと外部キーを追加します。

• 名簿レコードへの変更を格納するための一種のスキーマレステーブルを作成します。このようなテーブルは、AddressBookId、TimeStamp、FieldName、Valueで構成されます。このようにして、レコードへの変更のみを保存し、履歴テーブルと名簿テーブルの同期を維持する必要がなくなります。

• セラライズド（JSON）名簿レコードまたは名簿レコードへの変更を保存するテーブルを作成します。このようなテーブルは次のようになります：AddressBookId、TimeStamp、Object（varchar）。繰り返しますが、これはスキーマが少ないので、履歴テーブルとアドレスブックテーブルの同期を維持する必要はありません。（これは、CouchDBを使用した単純なドキュメントのバージョン管理をモデルにしています）

モジュールを積極的に開発しており、変更を本番サイトにプッシュする場合、通常、いくつかの構成変更を行う必要があります。これを自動化できたらいいのに…と思いませんか？

Webの周りを読んだり、スタックオーバーフローをしたり、コーディングホラーからリンクされたdbバージョン管理に関するこれらの記事のほとんどに基づいて、8年前のphpmysqlWebサイトのデータベースをバージョン管理する計画を立てました。

私の最初の質問は、この音は正しいですか？
私の2番目の質問は、コミットプロセスは、1日に2回以上実行するのは少し複雑に思えます。それを確実に自動化する方法はありますか？または、データベースの変更を問題になるほど頻繁にコミットするべきではありませんか？

私たちはドクトリン移行を使用していますが、移行に複数のアクションが含まれていて、そのうちの1つが失敗すると、問題が発生することがよくあります。

たとえば、5つの外部キーを追加する移行があり、フィールドの長さが同じでないときに5つ目が失敗した場合、フィールドでエラーを修正して移行を再生成しても全体は修正されませんが、エラーが発生します。キーの4つがすでに存在し、移行を正常に実行できないことに関連しています。

前述のような明らかな問題なしにDoctrineの移行を使用する安定した方法はありますか？以前はファイルを使用.sqlしていましたが、実際にはそれほど良くはありませんが、Doctrineを使用するプロジェクトのデータベースバージョン管理の正しい方法があると確信していますか？

モデルとスキーマの違いに基づいて移行を生成することは素晴らしいことであり、この可能性をさらに維持したいと思います。

ありがとう

シナリオを考えてみましょう: バージョン管理された異なるテーブルから複数の行を含む Db トランザクション。

例: shopLists と製品。shopList に商品 (ショップリストにある商品の量) が含まれていて、商品に現在の在庫がある場合。

shopList を挿入または編集するときに、shopList 内のこれらの製品の在庫を更新して、在庫を一定に保つ必要があります。

そのために、トランザクションを開き、shopList を挿入/更新し、各製品の在庫を更新 (デルタを適用) してから、トランザクションをコミットします。今のところ大したことはありません。

ただし、他のユーザーが共通して 1 つまたは複数の製品を更新した可能性があります。または、shopList 自体を更新することもできます。どちらの場合も、トランザクションをコミットするときに StaleObjectStateException が発生します。

質問: StaleObjectStateException の原因となったテーブルを特定する方法はありますか?

製品が例外を引き起こした場合、関連するすべての製品を DB から更新してから、在庫デルタを再適用できます。そして、それは結構です。shopList が例外を引き起こした場合は、ユーザーが最初からやり直すことができるように、単に問題をユーザーに報告することをお勧めします。

どうもありがとうございました。