An ecommerce database should keep product identity, customer identity and order history understandable as separate records with explicit relationships. Start with a small record map, then test a changed product description and customer address against an existing fictional order. This shows which values are current reference data and which information the business expects to preserve with the transaction.
A customer’s current contact details and the delivery details used for an earlier order can answer different questions. Likewise, a product may change after a sale. Write the intended meaning of each field before assessing storage tables or integration payloads. The database design needs to support those meanings clearly enough for support, reporting and future system changes.
The original record-boundary exercise below uses fictional catalogue and customer data. Narrow examples come from WooCommerce’s HPOS and REST API developer documentation, retrieved on 24 October 2026. Broader store planning belongs with online stores and web development.
Which records should be mapped separately?
Draw the product, customer and order as separate boxes. Add the identifier used for each and the relationship the proposed system needs between them. Then list the transaction details that must remain interpretable after reference information changes. This is a proposed design exercise; the exact fields should come from the chosen application’s actual schema and requirements.
WooCommerce HPOS stores order data in dedicated custom tables. The HPOS developer guide describes a concrete storage approach for one part of the map. Keep that scope visible: the documented order-storage mechanism is an example to inspect, while product and customer relationships still need their own requirements.
HPOS includes separate order-address, operational-data and metadata tables. Ask the implementer to identify which application interface owns the values relevant to your record map. A table name can help a technical investigation, but the business owner also needs to understand the meaning of the information and when it changes.
Use the application’s documented data-access mechanism for the proposed exercise. The purpose is to assess record relationships and history, rather than modify database tables directly during a demonstration. Retain the observed identifiers so another reviewer can locate the same sample records through the supported interface.
Which order data is authoritative?
HPOS distinguishes authoritative tables from synchronised backup tables. HPOS reads and writes normal order activity through the authoritative tables. These documented roles help explain why two copies of a value may exist during a storage transition without having the same operational status.
HPOS prevents switching authoritative tables while orders await synchronisation. HPOS requires order identifiers to match between authoritative and backup stores. Include those qualifications if the proposed work touches order-storage compatibility. A comparison needs to identify the selected store and synchronisation state before interpreting apparent discrepancies.
Keep a storage migration separate from the basic record-boundary exercise. If the project later changes the active storage mechanism, define a dedicated test and recovery plan in a separate environment. The map developed here can help identify which records and relationships the migration check must preserve.
| Fictional record | Proposed question | Evidence to compare |
|---|---|---|
| Product A | Which identifier remains stable when its description changes? | Product reference and before-and-after values |
| Customer A | Which details describe the current customer? | Customer reference and intended update scope |
| Order A | Which details describe the original transaction? | Order reference and relevant stored values |
| Order address | What happens after a later customer-address change? | Historical order and current customer views |
| Integration payload | How are empty values and identifiers represented? | Actual documented response fields |
| Storage copy | Which source is operationally authoritative? | Active configuration and synchronisation evidence |
The table is an original acceptance sheet. Its expected outcomes should be agreed before the sample data is changed.
How should integration responses be interpreted?
WooCommerce’s REST API uses JSON request and response data. Its REST API guide documents the representation an integration may receive. Retain the actual response used in the exercise privately, with sensitive fields excluded from ordinary review material.
WooCommerce REST resource identifiers are returned as integers. WooCommerce REST dates use ISO 8601 formatting. Record the field and its meaning alongside the value so an integration does not confuse a display label, external reference and internal resource identifier.
WooCommerce core REST decimal monetary values are returned as strings. WooCommerce REST blank fields are generally null or empty strings rather than omitted. These are product-specific representation details to inspect when mapping records between systems. The receiving implementation should distinguish an absent value from a deliberate request to clear information according to the endpoint’s documented behaviour.
Ask the implementer to show the mapping of identifiers and relevant values for the fictional transaction. Keep the proposed transformation and the observed payload together. This makes an integration issue easier to trace than a screenshot showing only a final total or customer name.
Give each mapped value a business definition as well as a technical field name. Ask whether it describes the present account, a particular transaction or an integration reference. Keep that definition with the mapping so a later developer does not reuse a convenient field with a different meaning.
Original current-data versus order-history exercise
Create Product A, Customer A and Order A in a separate test store, using invented details. Write the expected identifiers and values on the sheet. State which information should represent the current catalogue or customer and which information the business needs to interpret the earlier transaction.
First, inspect all three records and their relationships through the supported application interface. Retain the sample references and relevant response fields. Then change the fictional product description and customer address separately. Reopen the existing order after each change and compare the observed values with the written requirement.
A difference from the expected outcome becomes a specific design question. Ask whether the requirement should change, whether another field represents the intended information or whether the proposed implementation needs adjustment. Preserve the evidence rather than editing several records until the display looks familiar.
Next, inspect a documented integration response for the sample records. Compare identifiers, date representation and empty values with the receiving mapping. Record any transformation needed and the person responsible for validating it. This keeps the data contract visible across the application boundary.
Finish with a reviewed record map and the observed results. The useful output is a clear statement of identity, relationships and historical meaning, supported by the actual chosen system. For integration workflow questions, see business systems. To discuss the record boundaries and remaining mapping decisions, get started with the exercise sheet.
By Spout Team. AI-assisted drafting by Codex using the linked primary documentation.