2

私は現在の仕事のために新しい小売 e コマース ストアフロントの開発を任されており、RoR を使用して、A) Rails の限られた知識で「実際の」プロジェクトを構築し、B) 経営陣に迅速なターンアラウンドとフィードバックを提供することを検討しています。 (彼らはこれをできるだけ早く終わらせたいと考えており、彼らの締め切りはかなり非現実的です。SEO/SEM を使用してマーケティングを開始できるように、何もない状態から実用的なモデルになるまでに数週間かかると話しているのですが、冗談ではありません。"上司がそれが未来だと聞いたからです）。

データベース構造は整っていますが、それはまったくひどいものであり、韻も理由もなしに一緒に投げ込まれたため、ほとんど無視して、新しいデータベースをゼロから作成します。ただし、アプリケーションにロードする必要がある既存のデータがあります (前述のように、これは e コマース アプリであり、製品データがあります)。このデータを使用可能な形式に変換する必要があるのは、サプライヤが暗号化された省略形の列名を提供し、特にカテゴリで非常に非正規化されているためです (以前に質問を投稿しました - 基本的に、カテゴリ テーブルには 6 つのフィールドがあります)。 、各カテゴリ/サブカテゴリに 1 つずつ、そのカテゴリが適用されない場合は一部が空白になります)。

私に再考を与えている2つの主な問題があります：

  1. 私が言ったように、データは「適切な」データベーススキーマに入れる必要があります。そのまま載せるわけにはいきません。そのための適切なデータ モデルについていくつかの考えがありますが、私の分析はまだ完了していません。さまざまなもの (products_categories、products_attributes、products_prices など) をリンクするための大量の結合テーブルが存在することになり、これらのテーブルは ID ではなく SKU によって製品をリンクします (以下を参照)。

  2. すべてのものには ID が既に生成されていますが、新しく追加するものには ID を自動生成する必要があります。これが成熟した RDBMS で問題になるとは思えませんが、Rails が ID 自体を生成するのが好きであることは知っています。また、ほとんどすべての製品関連のテーブルは、ID と I ではなく、SKU によってリンクされています (サプライヤから提供されたデータには、実際にはプレフィックスと在庫番号からなる複合キーがあり、これらを組み合わせて完全な SKU を構成しています)。これがパフォーマンスの問題になるかどうかはわかりません (もちろん、これらの列に手動でインデックスを作成して高速化することもできます)。ただし、これは、Rails の規則から脱却する必要があることを意味します。

要するに、市場投入までの時間と開発の容易さに関しては、Rails は良い選択かもしれないと思いますが、アプリケーションを開発する必要があるため、既存のデータ コンテンツを操作しなければならないことは苦痛になる可能性があります。それは「従来の」Rails アプリではなく、Rails の使用について大きな疑問を投げかけています。他にもいくつかの問題があります (Linux サーバーをセットアップする必要があることと、私が住んでいる地域には Rails 開発者がほとんどいないという事実があるため、会社を辞めた場合、基本的に更新/変更に関して彼らを人質に取っていることになります) . 私は進むべき最善の道について本当に確信が持てません。

4

4 に答える 4

1

私はそれほど昔と同じ状況にありました—会社のすべてのデータの10年分の価値を保持していたくだらないPHPアプリです。

私が行ったのは、移行モデルを作成し、各リソースをインポートするためのメソッドを追加することでした。

class Migration
  def migration_all
    self.jobs
  end

  def self.jobs
    ...
  end
end

これのすばらしい点は、ある注文リソースが別の注文リソースを参照する可能性があるため、インポートする注文リソースを調整できることです。また、dbスキーマを直接変更するメソッドを追加しました。既存の主キーを保持する必要がある場合の1つの優れたトリックは、「legacy_id」という名前のフィールドを作成し、既存の主キーをコピーし、完了したら、「id」フィールドを削除して、「legacy_id」フィールドの名前を変更することです。 'id'に追加し、新しい'id'フィールドにprimary_key制約を追加します。

于 2009-01-24T05:36:31.137 に答える
1

各製品の一意のキーとしてSKUを使用しないでください。標準のRailsインクリメントIDを使用してください。

SKUは、入力ミスなどにより変更される可能性があり、他のテーブルからのすべての参照を変更することは悪夢になります。現在のIDをSKU列に入力し、インデックスを作成して、他のテーブルの参照をRailsIDに更新します。

コントローラでProduct.find_by_sku（params [：sku]）を実行したり、/ products /：skuルートを設定したりすることができます。生成されていないIDをデータベースの主キーとして使用します。

于 2009-01-24T05:49:37.837 に答える
1

また、アプリの検証を通じて古いデータを実行して、大量の不整合やエラーを読み込まないようにすることもお勧めします。これにより、アプリがスムーズに実行され、修正可能な時点で既存のデータ エラーが強調表示されます。

既存のデータが既に存在するという理由だけで、そのデータが有効であると想定しないでください。

于 2009-01-24T09:59:36.597 に答える