SQLサーバーデータを新しいスキーマに移行する
MS Accessのスモールビジネスユニット（スタッフ8名、顧客10名）のために数人が最初に作成したデータベースがあります。元の「開発者」は、以前の雇用主によって2日間のMS Accessコースに送られた非オタクでした。設計は不十分でしたが、ユニットが大きくなるにつれて、データを管理する人が複数必要になるため、十分に機能しました。この時点で私はユニットに参加し、SQLサーバーをバックエンドとして使用し、アクセスフロントエンドを維持して、その時点で3人または4人のユーザーを許可することを提案しました。
現在、約40人のユーザーが50以上の企業顧客にサービスを提供しており、基本的に完全な混乱状態です。しかし、このツールは、ジョブキュー、誰が何をしているのか、いつ期限があるのか、誰のためであるか、そしてすべてのものを追跡するために必要です。それなしでは機能できませんでした。
だから私はそれを捨ててゼロから再構築して適切に行い、アクセスフロントエンドをその過程で捨てたいと思います。これを行っている間、現在のシステムを実行し続ける必要があります。新しいシステムを開発し、データを同期させる方法をいくつか開発して、より高いパワーが満たされるまで問題を起こさないまでしばらく並行して実行します。
いくつかの巨大なテーブルを取り、それらを新しいスキーマの適切なテーブルに正規化することを前提として、データの同期を維持する方法に関する提案や指針はありますか？
これは巨大なデータベースではなく、すべてのジョブをリストするメインテーブルは、たとえば毎月約1500レコード増加し、現在約100,000行あります。
私の考えは、テーブルに行バージョン列を追加してから、何かをハッキングしてそれを監視し、新しいスキーマに変換することでした。
もっと良い方法はありますか？
データの移行はそれ自体がジョブですデータの同期を維持することはさらに別のジョブです。新しいフロントエンドを作成することはさらに別の仕事です。
この問題に取り組む方法はたくさんあります。
データの移行には多くの問題が発生する可能性があるため、これまでに一度も行ったことがない場合は、ビジネスが怒鳴らない限り、非常にゆっくりと慎重に移動します。
1つ目は、スキーマを複製し、SQLに単純にインポートするだけです。
そこから、新しいスキーマの外観を構築し、新しいスキーマにデータを移動するためのスクリプトを作成します。挿入、更新、削除などのすべてのログを記録していることを確認します。実行したコマンドをログに記録するのが最も簡単です。それを移動し、中央のテーブルで操作を元に戻すコマンド。
次に、それに対して新しいフロントエンドを構築し、徹底的にテストします。
次に、アクセスからエクスポートし、新しいスキーマにインポートするためにスクリプトをテストします。次に、少なくとも100回ほど実行するたびに完全に実行されるまで、エクスポートインポートプロセスを自動化して、移動前にプロセスをテストできます。
新しいプロセスとアプリケーションでビジネスから賛同を得て、スイッチの時間を設定するまでは、同期を保つ必要はありません。
2つの同時システムを配置する必要がある場合、まったく異なる一連の問題が発生します。
どちらが真実の情報源になりますか？いつでもすべてのデータをエクスポートしてアクセスできるようにする必要がありますか。
スコープのほぼすべての変更は、プロジェクトに追加の時間を追加します。
他にご不明な点がございましたらお問い合わせください。フラットファイルからsql、sqlへのアクセス、sqlからaccessへ、OracleからMongoDB、SQLからMongodb、mysqlからsql、mongodbからSQLへのこれらの小規模なデータ移行を約50ほど実行しました。あなたがそれを正しくしたいなら、あなたが思うよりもずっと長くかかります。
おそらく簡単な方法は、すべてのMS-Accessテーブルを、SQL Serverのビューへのリンクに置き換えて、古いAccessテーブルとまったく同じ構造にすることです。ビューが十分に単純である場合（たとえば、主キーと変更されていない列を含む単一のテーブルからのselectステートメント-名前を変更する以外の方法）は、直接更新可能です。それ以外の場合は、 pdatable views を使用できます。