0

レガシー データベースを使用しています。命名規則はいたるところにあり、一貫性がありません。Ruby on Rails アプリを作成していますが、Rails の組み込み機能でデータベースがうまく機能していないことは明らかです。これが私たちの戦略であり、いくつかの意見を得たいと思っていました：

  1. 新しいデータベースを作成し、Rails アプリをこのデータベースに向けます
  2. 古いデータベースのテーブル/列を、レールに適した新しいテーブル名/列名にマッピングします
  3. map を使用してビューを生成し、Rails アプリがこれらのテーブルが本物であると「考える」ようにします。
  4. 発展させる
  5. Rails アプリが古い UI を引き継いで、実際のデータをビューではなく実際のテーブルに移行する準備ができたら、元に戻ります

私が直面している問題は、この MySQL ビュー生成スクリプトを Rails アプリに適合させる方法です。このようなものは、ファイル構造のどこに収まりますか? ある種のプラグインとして？

テーブル マッピング:

+--------------------+------------------+------+-----+---------+----------------+
| Field              | Type             | Null | Key | Default | Extra          |
+--------------------+------------------+------+-----+---------+----------------+
| id                 | int(11) unsigned | NO   | PRI | NULL    | auto_increment |
| database           | varchar(64)      | NO   |     |         |                |
| current_name       | varchar(64)      | NO   |     |         |                |
| current_pk         | varchar(64)      | YES  |     | NULL    |                |
| new_system_prefix  | varchar(255)     | YES  |     | NULL    |                |
| new_format         | varchar(255)     | YES  |     | NULL    |                |
| new_vendor         | varchar(255)     | YES  |     | NULL    |                |
| new_name           | varchar(64)      | YES  |     | NULL    |                |
| new_pk             | varchar(64)      | YES  |     | NULL    |                |
| notes              | varchar(255)     | YES  |     | NULL    |                |
+--------------------+------------------+------+-----+---------+----------------+

列のマッピング:

+-----------------+------------------+------+-----+---------+----------------+
| Field           | Type             | Null | Key | Default | Extra          |
+-----------------+------------------+------+-----+---------+----------------+
| id              | int(11) unsigned | NO   | PRI | NULL    | auto_increment |
| table_id        | int(11) unsigned | YES  | MUL | NULL    |                |
| current_name    | varchar(255)     | YES  |     | NULL    |                |
| current_type    | varchar(255)     | YES  |     | NULL    |                |
| current_default | varchar(255)     | YES  |     | NULL    |                |
| new_name        | varchar(255)     | YES  |     | NULL    |                |
| new_type        | varchar(255)     | YES  |     | NULL    |                |
| new_default     | varchar(255)     | YES  |     | NULL    |                |
| extra           | varchar(255)     | YES  |     | NULL    |                |
| notes           | varchar(255)     | YES  |     | NULL    |                |
+-----------------+------------------+------+-----+---------+----------------+
4

1 に答える 1

1

DDD パターンの 1 つである Anticorruption レイヤーについて少し読むことをお勧めします。このパターンの主な原則は、対話するレガシー システムからモデルを保護することです。オプションの 1 つは、リポジトリを作成し、そこでレガシー データベースを処理するすべてのクエリをカプセル化することです。リポジトリは、レガシー データベースと新しいモデルの間のトランスレーターとして機能します。エンティティへのデータベース フィールドのマッピングも、リポジトリによって行われます。

于 2012-06-29T15:39:36.020 に答える