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

この記事では、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 を使用することをお勧めします。 拡張属性を使用して追加データを保存すると、次の利点があります。

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

他の選択肢を検討する

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

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

コアテーブルまたはサードパーティのテーブルの変更

コア Adobe Commerce ードまたはサードパーティのモジュールデータベーステーブルを変更してデータを保存する場合は、次のガイドラインを使用して、安定性とパフォーマンスに対する影響を最小限に抑えます。

外部データベーステーブルの変更に関するベストプラクティス

Adobeでは、コアデータベーステーブルまたはサードパーティのテーブルに列を追加する場合、次の手順に従うことをお勧めします。

潜在的な影響

外部データベースへの列の追加は、次の点でAdobe Commerce プロジェクトに影響を与える可能性があります。

コアテーブルの変更を回避する方法

extension attributes を使用すると、Adobe Commerceのデータベーステーブルを変更するのを避けることができます。 また、いくつかのコアテーブルにある特別な列（additional_data）を使用してデータを保存し、JSON エンコード形式で保存することもできます。

JSON エンコードされたデータ列にデータを保存

一部のコアテーブルには、JSON エンコードされたデータを格納する additional_data 列があります。 この列は、1 つのフィールドに追加のデータをマッピングするネイティブな方法を提供します。 この方法を使用すると、検索を必要とせずに、データ検索用の情報を格納する小さな単純なデータ要素のテーブルを追加する必要がなくなります。 additional_data 列は通常、品目レベルでのみ使用でき、見積もりや受注全体では使用できません。

列と additional_data 列の構造を持つテーブルの例を次に示します。

MariaDB [main]> DESCRIBE quote_item additional_data;
+-----------------+------+------+-----+---------+-------+
| Field           | Type | Null | Key | Default | Extra |
+-----------------+------+------+-----+---------+-------+
| additional_data | text | YES  |     | NULL    |       |
+-----------------+------+------+-----+---------+-------+
1 row in set (0.001 sec)


MariaDB [main]> DESCRIBE sales_order_item additional_data;
+-----------------+------+------+-----+---------+-------+
| Field           | Type | Null | Key | Default | Extra |
+-----------------+------+------+-----+---------+-------+
| additional_data | text | YES  |     | NULL    |       |
+-----------------+------+------+-----+---------+-------+
1 row in set (0.001 sec)

バージョン 2.4.3、2.4.4 および 2.4.5 には、列 additional_data を持つテーブルが 10 個あります。

MariaDB [magento]> SELECT DISTINCT TABLE_NAME FROM INFORMATION_SCHEMA.COLUMNS WHERE COLUMN_NAME IN ('additional_data') AND TABLE_SCHEMA='main';
+------------------------+
| TABLE_NAME             |
+------------------------+
| sales_shipment_item    |
| sales_creditmemo_item  |
| sales_invoice_item     |
| catalog_eav_attribute  |
| sales_order_payment    |
| quote_address_item     |
| quote_payment          |
| quote_item             |
| magento_reward_history |
| sales_order_item       |
+------------------------+
10 rows in set (0.020 sec)