問題タブ [refactoring-databases]

避けられれば、同じことを2か所で定義するのは好きではありません。

以下の2つのクエリは、2つの異なるテーブルを処理していることを認識していますが、これらのテーブルは基本的に同じ種類のデータを保持しており（異なる述語は、2つのクエリを保証します）、以下の2つの予測は「2つの場所で定義された同じもの」と考えています。 。

後でこれらのクエリを変更して別の列を含める場合は、常に予測を同じままにしておく必要があります。

それを前提として、動的SQLを使用せず、プロジェクションに「*」を使用しない場合（実稼働環境では許可されていません）、「列セット」を1回定義して、両方のクエリで使用できますか？

データベースを最適化する過程にあり、テーブルの一部の列のデータ型を DATETIME から SMALLDATETIME に変更することを考えていました。

ストア プロシージャの内容/コードと従属テーブルの両方を返すシステム ストアド プロシージャはありますか?

乾杯！

EDIT1：

依存関係を追跡するのではなく、ストアド プロシージャの名前をプログラムで変更しようとしています。

私は、何年にもわたる開発が行われている SQL サーバー データベースに基づくシステムに取り組んでいます。データ量はそれほど大きくありません (数 GB) が、非常に複雑です (数百のテーブル、数百のストアド プロシージャ)。

使わなくなったものをきれいにすることから始めたいと思います。毎週/毎月/四半期/年次のサイクルがあるため、1 年間使用されないものもあります。ただし、数か月間使用されていないものの短いリストがある場合は、検査によってそれらがまだ有用かどうかを判断できる場合があります.

私の意図は、すべてのデータベース オブジェクトへのアクセスのログ記録を開始することです。いくつかのアイデアがありますが、私が欲しいのは、使用されていないもののリストに変えることができるログです。いくつかのアイデアがありますが、専門家の助けが必要です。

編集：テーブル/ビュー、およびストアドプロシージャと関数へのアクセスを確認したいことも明確にしたいと思います。

データベースのリファクタリングに興味があります。私は、大量のデータを持たないいくつかのデータベースを扱っています。数 GB で、多くても数十万行です。ただし、数百、場合によっては数百のテーブル、ビュー、sproc、および関数があります。一部の場所では、スキーマを使用した分割と規則の戦略が実装されており、テーブルの所有権/使用状況を確認する際の問題を解決しています。ただし、オブジェクトの結合にはあまり役立っていません。

共有データベースを介した統合は良いことではないと誰もが読んでいますが、少なくともしばらくの間、すべてがデータベースにあるため、非常に生産的なものであることも知っています. オブジェクトに対して行うように、単一責任の原則をデータベースに適用することはありません。

編集：データベースのパフォーマンスに問題がないことを追加する必要があります。テーブルは大きくなく、最大でも数十万行しかありません。実際のデータベース パフォーマンスの問題はありません。ただし、データベースのスキーマ/ロジック/実装が非常に非効率な場合 (たとえば、レポートのデータを前処理するために、結果セットの各行に対してカーソルで sproc を実行する必要がある場合など) は除きます。これらを変更する必要があるとあなたが言う前に、それが要点です。データベースが変更の影響を評価できる状態になくなったため、変更できません。

明らかに、ある時点で「もう十分だ！」と言うでしょう。メッセージ、ETL、アプリケーション層などで接続された複数のデータベースに分割します

問題は、いくつが多すぎるかということです。あなたが気が狂う前に持つことができるsproc/テーブル/関数の数の絶対的な上限は何ですか?

行レベルのコンテンツでバージョン管理を実行できるストレージエンジンタイプが存在するかどうか疑問に思っていました。たとえば、ID、名前、値、およびIDがPKである単純なテーブルがある場合、行354は（354、 "zak"、 "test"）v1として開始され、その後（354、 "zak"、 "これは値のバージョン2"）v2であり、ID = 354のselecthistory（value）のような行の変更履歴を確認できます。

これは一種の難解なことですが、変更が加えられるたびにこれらの個別の履歴テーブルと関数を書き続ける必要はありません...

SQL Serverでは、スキーマの変更がストアドプロシージャ（および/またはビュー）に影響を与えるかどうかを確認する方法はありますか？
たとえば、1つのテーブルの列名を変更すると、一部のストアドプロシージャが破損する可能性があります。影響を受けるストアドプロシージャを確認する方法は？

これはかなり一般的なクエリかもしれませんが、今のところ良い答えを見つけることができませんでした。

これが私の質問です：

varchar列Titleを持つContactsという名前のテーブルがあります。開発の途中で、フィールドTitleをContactTitlesテーブルの外部キーであるTitleIDに置き換えたいと思います。現在、テーブルContactsには60を超える依存関係があります（他のテーブル、ビュー関数）。

どうすればそれを最も安全で簡単な方法で行うことができますか？

使用するもの：MSSQL 2005、データはすでに移行されています。スキーマを変更したいだけです。

編集：

迅速な再生をしてくれたAllに感謝します。

前述のように、連絡先テーブルには60を超える依存関係がありますが、次のクエリを実行すると、そのうち5つだけがタイトル列を使用します。移行スクリプトが実行されたため、データを変更する必要はありません。

/*gets all objects which use specified column */

SELECT Name FROM syscomments sc JOIN sysobjects so ON sc.id = so.id WHERE TEXT LIKE '%Title%' AND TEXT LIKE '%TitleID%'

次に、これらの5つのビューを確認し、手動で更新しました。

MySQL のフィールド (および/またはテーブル) の暗号化に関するガイダンスを探しています。まともなチュートリアルで解決しますが、暗号化されていないスキーマから暗号化されたフィールドを使用するスキーマへの移行を管理するための具体的なヒントが本当に欲しいです。ありがとう！

ちょっとした掃除のために、MySQLデータベース（異なるハードウェア）間で25個のテーブルを移動しています。これは完全なデータベースではなく、数百のうち25のテーブルです...これらのテーブルは実際にはそこに属していません。NDAの理由から理由については説明しません。

さて、これは多くのコードとSQ​​Lクエリを壊そうとしています。

これを行うための最良の方法は何ですか？

1. それらを一度に移動します。

2. それらを1つずつ移動します

-

それらを一度に移動するのはいいことです。私が見逃したいくつかの停止や壊れたコードかもしれませんが、それらをブロックとして移動する方がはるかに高速で、コードのプッシュに費やす時間が少なくなります。

それらを1つずつ移動することは、大きなものが壊れる可能性が少ないという点で優れていますが、作業のマイクロ管理、冗長な作業、および展開に多くの時間が費やされます。

しばらくの間、2つのデータベース間でテーブルをミラーリングすることは可能ですか？おそらく連合テーブル？

-

その他の情報：25のテーブルがあり、すべてコンテンツによって相互に関連付けられています。

一度に何時間もデータベースをシャットダウンできません。約5分のダウンタイムが許容されます。

-

このすべてのデータを移動し、コード、SQL、および私を良好な状態に保つための最善の方法は何ですか？

テーブルを新しいデータベースに複製する方法として、テーブルを統合できますか？

-ダニエル

裏話

プライマリテーブルの1つでNaturalKey列を廃止することを計画している職場で。プロジェクトは、このテーブル/列にリンクする100以上のアプリケーションで構成されています。この列を直接参照する400以上のストアドプロシージャ。また、この列を参照する、これらのアプリケーション間の膨大な数の共通テーブル。

BigBangとStartfromScratchの方法は理解できません。このコラムを一度に1つのアプリケーションで非推奨にし、変更を認証して、次の列に進みます...そして、この取り組みを実用化するための長い目標があります。

私が抱えている問題は、これらのアプリケーションの多くがストアドプロシージャとテーブルを共有していることです。アプリケーションAのすべてのテーブル/ストアドプロシージャを完全に変換すると、アプリケーションBとCは変換されるまで壊れます。これらは順番にアプリケーションD、E、F...Etcを壊す可能性があります。私はすでにコードクラスとストアドプロシージャのために実装された戦略を持っています、私が立ち往生している部分はデータベースの遷移状態です。

これが私たちが持っているものの基本的な例です：

そして、私たちは今、このような移行状態を目指しています：

移行フェーズでは、移行されていないアプリケーションとストアドプロシージャは引き続きすべての適切なデータにアクセスでき、新しいデータは正しい列にプッシュを開始できます。すべてのストアドプロシージャとアプリケーションの移行が完了すると、最終的に余分な列を削除します。

SQL Serverのトリガーを使用して、新しい挿入/更新を自動的にインターセプトし、影響を受ける各テーブルに対して次のようなことを実行したいと思いました。

質問

私がこれまでに抱えている2つの大きな問題は次のとおりです。

1. NULL制約により挿入が失敗するため、「AFTERINSERT」を実行できません。
2. 私が言及した「不可能なコード」は、元のクエリをきれいにプロキシしたい方法です。元のクエリにx、y、z列が含まれている場合、またはxだけの場合、理想的には同じトリガーでこれらを実行します。また、別の列を追加/削除する場合は、トリガーを機能させたままにします。

これが可能なコード例、または値の1つだけがSQLに渡された場合でもこれらの列を適切に入力し続けるための代替ソリューションさえありますか？