PaaS のみ

データベーステーブルを変更する際のベストプラクティス

最終更新日： 2025年5月5日

作成対象：

  • 経験者
  • 開発者

この記事では、Adobe Commerce またはサードパーティのモジュールで作成されたデータベーステーブルを変更するためのベストプラクティスを示します。 テーブルを効果的に変更するタイミングと方法を理解することで、コマースプラットフォームの長期的な実行可能性と安定性を確保できます。

Magento 1 やその他の e コマースプラットフォームから移行したり、Adobe Commerce Marketplace のモジュールを操作したりするには、追加データを追加して保存する必要がある場合があります。 最初の例として、データベース テーブルにカラムを追加したり、既存のカラムを調整したりすることがあります。 ただし、変更する必要があるのは、コア Adobe Commerce テーブル（またはサードパーティのベンダーテーブル）の場合に限られます。

Adobeが変更を避けることを推奨する理由

コアテーブルを変更しない主な理由は、Adobe Commerceに生の SQL クエリを含む基礎となるロジックが含まれているからです。 テーブルの構造を変更すると、予期しない副作用が発生する可能性があり、トラブルシューティングが困難になる場合があります。 また、この変更は DDL （データ定義言語）操作に影響を与え、予期しない予期しないパフォーマンスへの影響を引き起こす可能性があります。

データベーステーブルの構造の変更を避けるもう 1 つの理由は、コア開発チームまたはサードパーティの開発者がデータベーステーブルの構造を変更した場合、変更によって問題が発生する可能性があることです。 例えば、additional_data という列を持つコアデータベーステーブルがいくつかあります。 これは常に text 列タイプです。 ただし、パフォーマンス上の理由から、コアチームが列を longtext に変更する場合があります。 このタイプの列は JSON のエイリアスです。 この列タイプに変換すると、その列にパフォーマンスの向上と検索性が追加されますが、text の列タイプとしては存在しません。 このトピックについて詳しくは、JSON データタイプを参照してください。

データを保存または削除するタイミングを把握する

Adobeでは、まずこのデータを保存する必要があるかどうかを判断することをお勧めします。 レガシーシステムからデータを移動する場合、削除できるデータがあれば、移行中の時間と労力を節約できます。 （後でアクセスする必要がある場合は、データをアーカイブする方法があります）。 アプリケーションとパフォーマンスを適切に管理するために、追加のデータを保存するリクエストに挑戦しても問題ありません。 目標は、別の方法では実現できないビジネスニーズを満たすために、データを保存することが要件であることを確認することです。

レガシーデータ

古い注文や顧客レコードなどの従来のデータがプロジェクトに含まれている場合は、別の参照方法を検討してください。 例えば、ビジネスで、一時的な参照のためにデータへのアクセスのみを必要とする場合は、古いデータを Adobe Commerce に移行する代わりに、コマースプラットフォームの外部でホストされている古いデータベースに外部検索を実装することを検討します。

この状況では、データベースをサーバーに移行し、データを読み取るための web インターフェイスを提供するか、MySQL Workbench または同様のツールの使用に関するトレーニングを提供する必要があります。 新しいデータベースからこのデータを除外すると、開発チームがデータ移行の問題のトラブルシューティングではなく新しいサイトに集中できるので、移行が迅速化されます。

データをコマースの外部に保持しても、リアルタイムで使用できるもう 1 つの関連するオプションは、GraphQL メッシュなどの他のツールを活用することです。 このオプションは、様々なデータソースを組み合わせ、単一の応答として返します。

例えば、外部データベース（廃止された古いMagento 1 サイトなど）からの古い注文を一 stitch にまとめることができます。 次に、GraphQL メッシュを使用して、顧客の注文履歴の一部として表示します。 これらの古い注文は、現在の Adobe Commerce 環境の注文と組み合わせることができます。

GraphQLでの API メッシュの使用について詳しくは、API メッシュとは）および GraphQL Mesh Gateway を参照してください。

拡張属性を持つ従来のデータの移行

従来のデータを移行する必要がある場合、または新しいデータを Adobe Commerce に保存する必要がある場合は、Adobeでは extension attributes を使用することをお勧めします。 拡張属性を使用して追加データを保存すると、次の利点があります。

  • 永続化するデータおよびデータベース構造を制御できます。これにより、データが正しい列タイプおよび適切なインデックスで保存されます。
  • Adobe Commerce のほとんどのエンティティは、拡張属性の使用をサポートしています。
  • 拡張属性は、ストレージに依存しないメカニズムで、プロジェクトに最適な場所にデータを柔軟に保存できます。

格納場所の 2 つの例は、データベース・テーブルと Redis です。 場所を選択する際に考慮すべき重要な事項は、場所によって複雑さが増すか、パフォーマンスに影響を与えるかです。

他の選択肢を検討する

GraphQL メッシュやAdobe App Builderなど、Adobe Commerce 環境以外のツールの使用を常に検討することが開発者にとって不可欠です。 これらのツールは、データへのアクセスを保持するのに役立ちますが、コアコマースアプリケーションやその基礎となるデータベーステーブルには影響しません。 このアプローチでは、API を通じてデータを公開します。 次に、データソースをApp Builder設定に追加します。 GraphQL Mesh を使用すると、これらのデータソースを組み合わせ、 従来のデータで説明されているように 1 つの応答を生成できます。

GraphQL メッシュについて詳しくは、GraphQL Mesh Gateway を参照してください。 App BuilderのAdobeについて詳しくは、App Builderの概要を参照してください。