You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@iotdb.apache.org by Yuan Tian <ja...@gmail.com> on 2026/02/06 07:47:21 UTC
[DISCUSS] Terminology choice: "Table Model" vs. "Table Mode" (and Tree)
*Hi all,*
I would like to initiate a discussion regarding the official English
terminology for our dual-modeling capabilities in Apache IoTDB.
Specifically, should we use *"Table Model"* and *"Tree Model"*, or *"Table
Mode"* and *"Tree Mode"*?
After some consideration, I highly recommend adopting *"Table Model"*
and *"Tree
Model"*. Here is the reasoning based on classic database architecture:
As we know, the standard *three-level schema architecture in database
theory* consists of the External Schema (User Level), Conceptual Schema
(Logical/Model Level), and Internal Schema (Physical Level). This structure
ensures data independence by isolating user views from physical storage.
In the context of IoTDB:
-
*Unified Physical Layer:* Both "Tree" and "Table" share the same
underlying physical storage format (TsFile).
-
*Conceptual Distinction:* The primary difference lies in the *Conceptual
Schema*—the way we model the data. Each modeling approach carries its
own unique logic, constraints, and mappings.
-
*External Impact:* These different conceptual models further determine
their respective External Schemas and query syntaxes.
If we were to use "Mode," it might imply a superficial switch in "External
Schema" or "syntax style." However, *"Model"* accurately reflects that we
are providing two different logical frameworks for data representation on
top of a unified storage engine.
I would love to hear your thoughts on this. Do you agree with using
"Model," or do you see any advantages to using "Mode"?
*Best regards,*
Yuan Tian
Re: [DISCUSS] Terminology choice: "Table Model" vs. "Table Mode" (and Tree)
Posted by Wang Critas <cr...@outlook.com>.
hi,
Model + 1
I think "Model" is more accurate: This refers to the core logical structure for data organization, storage, and representation—it's a design paradigm or architecture. It describes "what the data looks like."
Industry Convention: In the field of databases and system design, similar terms consistently use "Model," for example:
Relational Model
Document Model
Hierarchical Model (conceptually similar to Tree Model)
Distinction from "Mode": Mode typically refers to an operational mode or state (e.g., read-only mode, compatibility mode), focusing more on how the system operates rather than how data is structured.
Best regards,
Xuan Wang
________________________________
From: Yuan Tian <ja...@gmail.com>
Sent: Tuesday, February 10, 2026 8:04:24 AM
To: dev@iotdb.apache.org <de...@iotdb.apache.org>
Subject: Re: [DISCUSS] Terminology choice: "Table Model" vs. "Table Mode" (and Tree)
Hi Chris,
That's a great distillation of the core difference. The persistence of the
underlying schema strongly favors 'Model,' making the term 'Mode'
inaccurate for the conceptual layer. Based on the discussion, I feel we can
move forward with officially adopting 'Model.'
what do others think?
Best,
Yuan
On Mon, Feb 9, 2026 at 18:13 Christofer Dutz <ch...@c-ware.de>
wrote:
> Hi,
>
> So as far as I understood things: If you write data into a tree model
> storage, the you can only access it with tree queries. If you write into
> table model, then you can only use table queries.
> So I would stick to „Model“.
>
> If it was possible to write to the storage using tree and/or table model
> and you could query data using either a tree syntax or a table syntax, then
> I’d call it „Mode“.
>
> Mode for my implies I get to chose: "How do I want to access this? Tree or
> Table mode?“ … Modes can be switched, models can’t.
>
> Just my 5ct on this 😉
>
> Chris
>
>
> Von: Pengcheng Zheng <ma...@gmail.com>
> Datum: Montag, 9. Februar 2026 um 10:14
> An: dev@iotdb.apache.org <de...@iotdb.apache.org>
> Betreff: Re: [DISCUSS] Terminology choice: "Table Model" vs. "Table Mode"
> (and Tree)
>
> Hi Yuan,
>
> Thanks for starting this thoughtful discussion — I find the distinction
> very valuable.
>
> I’d like to add one perspective from an engineering and user-facing angle.
> While I fully agree that Tree and Table represent two different logical
> data models at the conceptual schema level, in IoTDB they are built on the
> same physical storage (TsFile) and operate on the same underlying
> time-series data. From a user’s point of view, this often feels less like
> “choosing a model” and more like switching between two interoperable ways
> of accessing and reasoning about the same data.
>
> One possible way to articulate this externally could be: “IoTDB provides
> two logical data models — a Tree-oriented model and a Table-oriented model
> — exposed to users as two interchangeable access modes over the same
> underlying time-series data.”
>
> I’m curious how others see this trade-off between theoretical precision and
> user perception, especially in comparison with how “multi-model” is used
> elsewhere. Looking forward to more thoughts.
>
> Best regards,
>
> Pengcheng
>
> Am Fr., 6. Feb. 2026 um 15:48 Uhr schrieb Yuan Tian <
> jackietien97@gmail.com
> >:
>
> > *Hi all,*
> >
> > I would like to initiate a discussion regarding the official English
> > terminology for our dual-modeling capabilities in Apache IoTDB.
> > Specifically, should we use *"Table Model"* and *"Tree Model"*, or
> *"Table
> > Mode"* and *"Tree Mode"*?
> >
> > After some consideration, I highly recommend adopting *"Table Model"*
> > and *"Tree
> > Model"*. Here is the reasoning based on classic database architecture:
> >
> > As we know, the standard *three-level schema architecture in database
> > theory* consists of the External Schema (User Level), Conceptual Schema
> > (Logical/Model Level), and Internal Schema (Physical Level). This
> structure
> > ensures data independence by isolating user views from physical storage.
> >
> > In the context of IoTDB:
> >
> > -
> >
> > *Unified Physical Layer:* Both "Tree" and "Table" share the same
> > underlying physical storage format (TsFile).
> > -
> >
> > *Conceptual Distinction:* The primary difference lies in the
> *Conceptual
> > Schema*—the way we model the data. Each modeling approach carries its
> > own unique logic, constraints, and mappings.
> > -
> >
> > *External Impact:* These different conceptual models further determine
> > their respective External Schemas and query syntaxes.
> >
> > If we were to use "Mode," it might imply a superficial switch in
> "External
> > Schema" or "syntax style." However, *"Model"* accurately reflects that we
> > are providing two different logical frameworks for data representation on
> > top of a unified storage engine.
> >
> > I would love to hear your thoughts on this. Do you agree with using
> > "Model," or do you see any advantages to using "Mode"?
> >
> > *Best regards,*
> >
> > Yuan Tian
> >
>
Re: [DISCUSS] Terminology choice: "Table Model" vs. "Table Mode" (and Tree)
Posted by Yuan Tian <ja...@gmail.com>.
Hi Chris,
That's a great distillation of the core difference. The persistence of the
underlying schema strongly favors 'Model,' making the term 'Mode'
inaccurate for the conceptual layer. Based on the discussion, I feel we can
move forward with officially adopting 'Model.'
what do others think?
Best,
Yuan
On Mon, Feb 9, 2026 at 18:13 Christofer Dutz <ch...@c-ware.de>
wrote:
> Hi,
>
> So as far as I understood things: If you write data into a tree model
> storage, the you can only access it with tree queries. If you write into
> table model, then you can only use table queries.
> So I would stick to „Model“.
>
> If it was possible to write to the storage using tree and/or table model
> and you could query data using either a tree syntax or a table syntax, then
> I’d call it „Mode“.
>
> Mode for my implies I get to chose: "How do I want to access this? Tree or
> Table mode?“ … Modes can be switched, models can’t.
>
> Just my 5ct on this 😉
>
> Chris
>
>
> Von: Pengcheng Zheng <ma...@gmail.com>
> Datum: Montag, 9. Februar 2026 um 10:14
> An: dev@iotdb.apache.org <de...@iotdb.apache.org>
> Betreff: Re: [DISCUSS] Terminology choice: "Table Model" vs. "Table Mode"
> (and Tree)
>
> Hi Yuan,
>
> Thanks for starting this thoughtful discussion — I find the distinction
> very valuable.
>
> I’d like to add one perspective from an engineering and user-facing angle.
> While I fully agree that Tree and Table represent two different logical
> data models at the conceptual schema level, in IoTDB they are built on the
> same physical storage (TsFile) and operate on the same underlying
> time-series data. From a user’s point of view, this often feels less like
> “choosing a model” and more like switching between two interoperable ways
> of accessing and reasoning about the same data.
>
> One possible way to articulate this externally could be: “IoTDB provides
> two logical data models — a Tree-oriented model and a Table-oriented model
> — exposed to users as two interchangeable access modes over the same
> underlying time-series data.”
>
> I’m curious how others see this trade-off between theoretical precision and
> user perception, especially in comparison with how “multi-model” is used
> elsewhere. Looking forward to more thoughts.
>
> Best regards,
>
> Pengcheng
>
> Am Fr., 6. Feb. 2026 um 15:48 Uhr schrieb Yuan Tian <
> jackietien97@gmail.com
> >:
>
> > *Hi all,*
> >
> > I would like to initiate a discussion regarding the official English
> > terminology for our dual-modeling capabilities in Apache IoTDB.
> > Specifically, should we use *"Table Model"* and *"Tree Model"*, or
> *"Table
> > Mode"* and *"Tree Mode"*?
> >
> > After some consideration, I highly recommend adopting *"Table Model"*
> > and *"Tree
> > Model"*. Here is the reasoning based on classic database architecture:
> >
> > As we know, the standard *three-level schema architecture in database
> > theory* consists of the External Schema (User Level), Conceptual Schema
> > (Logical/Model Level), and Internal Schema (Physical Level). This
> structure
> > ensures data independence by isolating user views from physical storage.
> >
> > In the context of IoTDB:
> >
> > -
> >
> > *Unified Physical Layer:* Both "Tree" and "Table" share the same
> > underlying physical storage format (TsFile).
> > -
> >
> > *Conceptual Distinction:* The primary difference lies in the
> *Conceptual
> > Schema*—the way we model the data. Each modeling approach carries its
> > own unique logic, constraints, and mappings.
> > -
> >
> > *External Impact:* These different conceptual models further determine
> > their respective External Schemas and query syntaxes.
> >
> > If we were to use "Mode," it might imply a superficial switch in
> "External
> > Schema" or "syntax style." However, *"Model"* accurately reflects that we
> > are providing two different logical frameworks for data representation on
> > top of a unified storage engine.
> >
> > I would love to hear your thoughts on this. Do you agree with using
> > "Model," or do you see any advantages to using "Mode"?
> >
> > *Best regards,*
> >
> > Yuan Tian
> >
>
AW: [DISCUSS] Terminology choice: "Table Model" vs. "Table Mode" (and Tree)
Posted by Christofer Dutz <ch...@c-ware.de>.
Hi,
So as far as I understood things: If you write data into a tree model storage, the you can only access it with tree queries. If you write into table model, then you can only use table queries.
So I would stick to „Model“.
If it was possible to write to the storage using tree and/or table model and you could query data using either a tree syntax or a table syntax, then I’d call it „Mode“.
Mode for my implies I get to chose: "How do I want to access this? Tree or Table mode?“ … Modes can be switched, models can’t.
Just my 5ct on this 😉
Chris
Von: Pengcheng Zheng <ma...@gmail.com>
Datum: Montag, 9. Februar 2026 um 10:14
An: dev@iotdb.apache.org <de...@iotdb.apache.org>
Betreff: Re: [DISCUSS] Terminology choice: "Table Model" vs. "Table Mode" (and Tree)
Hi Yuan,
Thanks for starting this thoughtful discussion — I find the distinction
very valuable.
I’d like to add one perspective from an engineering and user-facing angle.
While I fully agree that Tree and Table represent two different logical
data models at the conceptual schema level, in IoTDB they are built on the
same physical storage (TsFile) and operate on the same underlying
time-series data. From a user’s point of view, this often feels less like
“choosing a model” and more like switching between two interoperable ways
of accessing and reasoning about the same data.
One possible way to articulate this externally could be: “IoTDB provides
two logical data models — a Tree-oriented model and a Table-oriented model
— exposed to users as two interchangeable access modes over the same
underlying time-series data.”
I’m curious how others see this trade-off between theoretical precision and
user perception, especially in comparison with how “multi-model” is used
elsewhere. Looking forward to more thoughts.
Best regards,
Pengcheng
Am Fr., 6. Feb. 2026 um 15:48 Uhr schrieb Yuan Tian <jackietien97@gmail.com
>:
> *Hi all,*
>
> I would like to initiate a discussion regarding the official English
> terminology for our dual-modeling capabilities in Apache IoTDB.
> Specifically, should we use *"Table Model"* and *"Tree Model"*, or *"Table
> Mode"* and *"Tree Mode"*?
>
> After some consideration, I highly recommend adopting *"Table Model"*
> and *"Tree
> Model"*. Here is the reasoning based on classic database architecture:
>
> As we know, the standard *three-level schema architecture in database
> theory* consists of the External Schema (User Level), Conceptual Schema
> (Logical/Model Level), and Internal Schema (Physical Level). This structure
> ensures data independence by isolating user views from physical storage.
>
> In the context of IoTDB:
>
> -
>
> *Unified Physical Layer:* Both "Tree" and "Table" share the same
> underlying physical storage format (TsFile).
> -
>
> *Conceptual Distinction:* The primary difference lies in the *Conceptual
> Schema*—the way we model the data. Each modeling approach carries its
> own unique logic, constraints, and mappings.
> -
>
> *External Impact:* These different conceptual models further determine
> their respective External Schemas and query syntaxes.
>
> If we were to use "Mode," it might imply a superficial switch in "External
> Schema" or "syntax style." However, *"Model"* accurately reflects that we
> are providing two different logical frameworks for data representation on
> top of a unified storage engine.
>
> I would love to hear your thoughts on this. Do you agree with using
> "Model," or do you see any advantages to using "Mode"?
>
> *Best regards,*
>
> Yuan Tian
>
RE: [DISCUSS] Terminology choice: "Table Model" vs. "Table Mode" (and Tree)
Posted by Stephen Lawrence <st...@renesas.com>.
Hi Pengcheng,
I think you bring up an important point for users that are not deeply following
the implementation details. When I first heard of the table introduction,
I had many unanswered questions in my mind about the implications for the
implementation:
Does the table model still use TsFile?
Does this instead mean new parallel components for storage and engine?
Would that ballon runtime requirements for those of us interested in running
a TS DB in-device?
Would IoTDB no longer be characterised as a TS columnar DB but some kind of
hybrid?
These and other questions were subsequently cleared up in our meeting, but
I think it is important that the project finds a good way to communicate
that the storage approach is the same. Even if it is to simply state that
it is same physical storage (TsFile) as you have done.
That simplifies the mental model for both users initially evaluating the
project and existing 1.x users: 'OK, it's all TsFile columnar storage
underneath I can concentrate on selecting the best model for my needs'.
In terms of mode vs model, personally I would use model. Whilst it could
be considered that you are 'switching mode' over the TsFile storage, I
think the more important point is that you are modelling a logical domain
in a specific schema structure in the IoTDB implementation.
When I think of the COVESA automotive data modelling, the Vehicle Signal
Specification (VSS) has a tree structure, and a user could take advantage
of the IoTDB tree model if tree traversal was important to them. The newer
Simplified Semantic Data Modeling (S2DM) is designed to allow freer
relationships between vehicle and other models. Here the decomposed nature
of the domains (seat, hvac, driver etc.) means the IoTDB table model might
be a better fit.
In either case, the mental and data models are all about modelling the
logical concepts (VSS, S2DM/VDM) and their implementation (IoTDB table/tree).
'Mode' seems to neither carry the importance or convey the activity.
Best wishes,
Steve Lawrence
Renesas Electronics
COVESA Data Architecture & Infrastructure team lead
> -----Original Message-----
> From: Pengcheng Zheng <ma...@gmail.com>
> Sent: 09 February 2026 09:13
> To: dev@iotdb.apache.org
> Subject: Re: [DISCUSS] Terminology choice: "Table Model" vs. "Table Mode"
> (and Tree)
>
> Hi Yuan,
>
> Thanks for starting this thoughtful discussion — I find the distinction
> very valuable.
>
> I’d like to add one perspective from an engineering and user-facing angle.
> While I fully agree that Tree and Table represent two different logical
> data models at the conceptual schema level, in IoTDB they are built on the
> same physical storage (TsFile) and operate on the same underlying
> time-series data. From a user’s point of view, this often feels less like
> “choosing a model” and more like switching between two interoperable ways
> of accessing and reasoning about the same data.
>
> One possible way to articulate this externally could be: “IoTDB provides
> two logical data models — a Tree-oriented model and a Table-oriented model
> — exposed to users as two interchangeable access modes over the same
> underlying time-series data.”
>
> I’m curious how others see this trade-off between theoretical precision
> and
> user perception, especially in comparison with how “multi-model” is used
> elsewhere. Looking forward to more thoughts.
>
> Best regards,
>
> Pengcheng
>
> Am Fr., 6. Feb. 2026 um 15:48 Uhr schrieb Yuan Tian
> <jackietien97@gmail.com
> >:
>
> > *Hi all,*
> >
> > I would like to initiate a discussion regarding the official English
> > terminology for our dual-modeling capabilities in Apache IoTDB.
> > Specifically, should we use *"Table Model"* and *"Tree Model"*, or
> *"Table
> > Mode"* and *"Tree Mode"*?
> >
> > After some consideration, I highly recommend adopting *"Table Model"*
> > and *"Tree
> > Model"*. Here is the reasoning based on classic database architecture:
> >
> > As we know, the standard *three-level schema architecture in database
> > theory* consists of the External Schema (User Level), Conceptual Schema
> > (Logical/Model Level), and Internal Schema (Physical Level). This
> structure
> > ensures data independence by isolating user views from physical storage.
> >
> > In the context of IoTDB:
> >
> > -
> >
> > *Unified Physical Layer:* Both "Tree" and "Table" share the same
> > underlying physical storage format (TsFile).
> > -
> >
> > *Conceptual Distinction:* The primary difference lies in the
> *Conceptual
> > Schema*—the way we model the data. Each modeling approach carries its
> > own unique logic, constraints, and mappings.
> > -
> >
> > *External Impact:* These different conceptual models further
> determine
> > their respective External Schemas and query syntaxes.
> >
> > If we were to use "Mode," it might imply a superficial switch in
> "External
> > Schema" or "syntax style." However, *"Model"* accurately reflects that
> we
> > are providing two different logical frameworks for data representation
> on
> > top of a unified storage engine.
> >
> > I would love to hear your thoughts on this. Do you agree with using
> > "Model," or do you see any advantages to using "Mode"?
> >
> > *Best regards,*
> >
> > Yuan Tian
> >
Re: [DISCUSS] Terminology choice: "Table Model" vs. "Table Mode" (and Tree)
Posted by Pengcheng Zheng <ma...@gmail.com>.
Hi Yuan,
Thanks for starting this thoughtful discussion — I find the distinction
very valuable.
I’d like to add one perspective from an engineering and user-facing angle.
While I fully agree that Tree and Table represent two different logical
data models at the conceptual schema level, in IoTDB they are built on the
same physical storage (TsFile) and operate on the same underlying
time-series data. From a user’s point of view, this often feels less like
“choosing a model” and more like switching between two interoperable ways
of accessing and reasoning about the same data.
One possible way to articulate this externally could be: “IoTDB provides
two logical data models — a Tree-oriented model and a Table-oriented model
— exposed to users as two interchangeable access modes over the same
underlying time-series data.”
I’m curious how others see this trade-off between theoretical precision and
user perception, especially in comparison with how “multi-model” is used
elsewhere. Looking forward to more thoughts.
Best regards,
Pengcheng
Am Fr., 6. Feb. 2026 um 15:48 Uhr schrieb Yuan Tian <jackietien97@gmail.com
>:
> *Hi all,*
>
> I would like to initiate a discussion regarding the official English
> terminology for our dual-modeling capabilities in Apache IoTDB.
> Specifically, should we use *"Table Model"* and *"Tree Model"*, or *"Table
> Mode"* and *"Tree Mode"*?
>
> After some consideration, I highly recommend adopting *"Table Model"*
> and *"Tree
> Model"*. Here is the reasoning based on classic database architecture:
>
> As we know, the standard *three-level schema architecture in database
> theory* consists of the External Schema (User Level), Conceptual Schema
> (Logical/Model Level), and Internal Schema (Physical Level). This structure
> ensures data independence by isolating user views from physical storage.
>
> In the context of IoTDB:
>
> -
>
> *Unified Physical Layer:* Both "Tree" and "Table" share the same
> underlying physical storage format (TsFile).
> -
>
> *Conceptual Distinction:* The primary difference lies in the *Conceptual
> Schema*—the way we model the data. Each modeling approach carries its
> own unique logic, constraints, and mappings.
> -
>
> *External Impact:* These different conceptual models further determine
> their respective External Schemas and query syntaxes.
>
> If we were to use "Mode," it might imply a superficial switch in "External
> Schema" or "syntax style." However, *"Model"* accurately reflects that we
> are providing two different logical frameworks for data representation on
> top of a unified storage engine.
>
> I would love to hear your thoughts on this. Do you agree with using
> "Model," or do you see any advantages to using "Mode"?
>
> *Best regards,*
>
> Yuan Tian
>