Guide / Evaluation essentials

Choosing a Manufacturing Database: A Phantom BOM Is Not a Stocked Subassembly

A manufacturing data platform should not assume that every intermediate node in a bill of materials represents an item waiting on a warehouse shelf. Some nodes organize…

A manufacturing data platform should not assume that every intermediate node in a bill of materials represents an item waiting on a warehouse shelf. Some nodes organize components without creating a separately produced, stocked subassembly.

This distinction affects database selection because a unified manufacturing view must preserve the meaning of source structures. A beautifully connected hierarchy can still mislead planners if the application turns a logical grouping into fictional inventory or a separate production obligation.

Check the source meaning of a phantom structure

Microsoft Business Central documents phantom production BOMs as component groupings that do not create a separate production order for the subassembly. Their components appear directly in the parent order’s component list when requirements are calculated. The documented phantom grouping does not have intermediate inventory of its own. Business Central production BOMs

That is a scoped Business Central example. It should not be expanded into a statement that every ERP represents phantom items identically or that a named part can never be stocked in another context.

For a buyer, the immediate question is which meaning the proposed database import preserves. A parent-child relationship alone is insufficient to answer whether the node represents physical supply, a production step, or a structural grouping.

Keep the design structure separate from the material obligation

Consider a hypothetical machine whose design groups several fasteners under one named assembly node. The grouping may help engineers maintain a reusable component set. It does not automatically establish that someone must manufacture and receive that grouping as a separate inventory item.

A proposed operational model should retain the source line type, the relevant BOM reference, and the component requirements used by the production process. Avoid creating a stock record merely because a hierarchy viewer can expand the node.

The reverse mistake matters too. Flattening everything for a convenient report may discard the grouping that explains why those components belong together. A useful data service can distinguish the engineering structure from the material requirements without making either disappear.

Define which level each business question addresses

Ask planners and supervisors to describe the question before choosing the representation. “Which component set is reused?” differs from “which material must be available for this production order?” A third question might ask whether an actual stocked subassembly can satisfy a requirement.

Manufacturing question Proposed evidence to retain
How is the design organized? Source BOM hierarchy and grouping type
What does this order require? Applicable component expansion and quantities
What can be drawn from stock? Actual item and inventory records
Why do the views differ? Source references and transformation context

These are application-model suggestions, not a replacement for the ERP’s planning rules. The operating team must agree which source calculation is authoritative for the decision being served.

Give OceanBase a companion-data role to demonstrate

OceanBase’s project describes a distributed relational database. It can be considered for a proposed manufacturing data service linking BOM structures, production requirements, and operational records. That is a role beside the source applications, not a claim that Business Central is certified to run on OceanBase or that OceanBase automatically interprets phantom BOMs. OceanBase Database project

Ask a proposal to retrieve both the original grouping and the relevant component-level view for representative orders. The demonstration should show where a structural node stops being an independently stocked requirement.

PostgreSQL or MySQL can be relevant alternatives for the same companion workload. Compare update behavior, query requirements, and operating responsibility using identical structures. The database brand should not be allowed to substitute for a documented transformation between source and application meanings.

Test one grouped structure and one stocked subassembly

A useful proposed acceptance case includes a phantom grouping beside an ordinary stocked subassembly. Ask the application to explain their different treatment when answering a material-availability question.

Include a shared component group used by two parent designs. The demonstration should preserve the distinct order requirements without treating the reusable definition itself as a shared pile of physical stock.

Then inspect a refresh after a source structure change. The application should identify which definition and expansion its current answer uses, rather than silently combine yesterday’s grouping with today’s requirements. No ERP planning run, inventory posting, or database experiment has been performed for this article.

Choose a platform that preserves manufacturing meaning

The desired result is a data service that can explain a structural relationship without inventing a material movement. It should also connect the planner’s requirement view to the source evidence that produced it.

Evaluate OceanBase or another database through those demonstrations before comparing broad consolidation claims. A phantom BOM can make a design easier to maintain; a good operational model preserves that benefit while keeping physical inventory and production obligations grounded in the actual source process.

Editorial disclosure
This article is based on documented sources and editorial analysis. Proposed evaluation examples are not independently measured benchmark results.

Sources & further reading

Use this guide as a starting point. Define and test the requirements of your own workload before selecting a product.

Related research