Can the same logical table use different storage models?

Yes. Its physical representation can vary while preserving the intended logical contents.

Does column organization always reduce query time?

No. The requested attributes, access pattern and implementation determine the result.

Is physical decomposition the same as changing the business schema?

Not necessarily. A storage engine can reorganize representation while presenting the same logical table.

AI Glossary / Data engineering and architecture / Advanced

Storage model

Definition

A storage model describes how data is physically organized in a data store, including how record attributes are grouped and represented for access. In database systems, familiar examples include storing attributes together by row or organizing values by column. This differs from a logical data model, which describes the data's structure and meaning at a higher level. The same logical table can have different physical arrangements.

What it means

A table displayed on screen does not reveal how its values are arranged underneath. Rows, columns and identifiers form a logical view that a storage engine must represent using memory or persistent storage. That representation influences what the system reads when a query asks for particular values. A design that conveniently retrieves whole records may have different costs from one that scans a few attributes across many records. The storage model therefore connects the application's access pattern with the physical work required, without changing what the data is supposed to mean.

How it works

An n-ary storage model groups a record's attributes together. A decomposition storage model organizes attributes separately while preserving a way to associate values with their records. Copeland and Khoshafian's original DSM paper examines a specific surrogate-based design, rather than proving that one arrangement always wins. Later research also examines layouts that balance row and column access. The model must be implemented through concrete structures, metadata and access methods. Compression, indexing and caching then interact with that layout, so a label such as row-oriented or column-oriented is only part of the performance explanation.

Three practical examples

A reporting workload reads one numerical attribute across many records, prompting an evaluation of how much unrelated data each layout brings into memory.
A service repeatedly retrieves complete records by identifier, making reconstruction and lookup costs relevant to its storage choice.
An AI feature pipeline compares physical representations while verifying that every feature remains associated with the correct entity.

Think of it this way

Imagine keeping complete customer forms in folders versus keeping separate lists for names, addresses and membership dates. A whole form is convenient when reviewing one customer; a date list is convenient when examining membership dates across everyone. Separate lists still need a reliable way to match entries. The analogy explains access tradeoffs without implying that a database literally stores paper forms or that either arrangement is always preferable.

Worked example

Consider an original simplified table with 1,000 records and 10 fixed-size attributes per record, each occupying 8 bytes. Ignore identifiers, metadata, compression, indexes and page boundaries for this calculation. The attribute payload totals 1,000 times 10 times 8 = 80,000 bytes. A query that needs only one attribute requires 8,000 bytes of useful values. Under an assumed full scan of the row-organized payload, 80,000 bytes are read. Under an assumed separate-column scan, the relevant payload is 8,000 bytes. The useful-payload ratio is ten to one. This is not a tenfold runtime guarantee: the assumptions exclude important implementation details. If the query instead needs every attribute of one record, the comparison changes, and the separate representation must identify and assemble the corresponding values correctly.

Illustrative case study

In a fictional learning-platform project, a nightly report scans two attributes across a large event table, while a support tool retrieves complete individual events. Engineers evaluate storage layouts using both workloads. They also verify that reorganizing values does not change identifiers, missing-value interpretation or query results. One report records bytes processed, another records observed latency and update cost. The team avoids declaring a universal winner from the nightly report alone. The scenario illustrates workload-based evaluation; it is not a benchmark of a named database and does not claim that changing the layout automatically improves the platform's AI features.

Common misconceptions and mistakes

A storage model is not simply the purchase model for disks or cloud capacity. It also differs from a logical schema: changing physical layout need not change the relationships users query. Another mistake is treating a payload-size calculation as a complete performance model. Indexes, compression, cache state and execution strategy can alter what is actually accessed and how long it takes. Finally, physical decomposition must preserve record associations. Sorting separate columns independently without retaining their correspondence would corrupt the intended records, even if each column still contained all its original values.

Business use

The concept helps teams explain why workload characteristics matter when evaluating data platforms. Identify whether important operations scan selected attributes, retrieve whole records, update frequently or combine these patterns. For AI preparation, include the cost of assembling the complete feature set and preserving entity alignment. Compare outputs as well as resource consumption, and test the workload mix that the service actually needs. A storage model offers a way to reason about tradeoffs; the business decision still requires evidence from the implementation, dataset and operational requirements rather than a general claim that columns or rows are always faster.

Check your understanding

What was the toy table's total attribute payload?

Answer: Eighty thousand bytes.

How much useful payload did the one-attribute query need?

Answer: Eight thousand bytes.

Why is the ten-to-one ratio not a runtime measurement?

Answer: The model excludes page handling, metadata and other execution costs.

What must be preserved when attributes are stored separately?

Answer: Their correct association with the records to which they belong.

Related terms

Row store
column store
n-ary storage model
decomposition storage model
physical data independence
record reconstruction

Learn next

Draw a three-row, three-attribute table and represent it once by rows and once by separate attributes with explicit record identifiers. Trace a single-column scan and a whole-record lookup in each representation. List the work each requires, then explain which additional implementation details would be needed before predicting actual execution time.

Sources

George P. Copeland and Setrag N. Khoshafian, A Decomposition Storage Model, 1985: https://sigmodrecord.org/publications/sigmodRecord/8505/pdfs/971699.318923.pdf Jiri Schindler and colleagues, Atropos: A Disk Array Volume Manager for Orchestrated Use of Disks, FAST 2004, especially the database-storage-model discussion: https://www.usenix.org/legacy/publications/library/proceedings/fast04/tech/full_papers/schindler/schindler_html/ The payload calculation, forms analogy and learning-platform scenario are original educational illustrations. Historical research explains layout tradeoffs; its hardware-specific performance results are not generalized to present-day systems.

Previous: Storage area network Next: Straight-through estimator