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

この記事では、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 を参照してください。