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 <[email protected]> Sent: Tuesday, February 10, 2026 8:04:24 AM To: [email protected] <[email protected]> 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 <[email protected]> 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 <[email protected]> > Datum: Montag, 9. Februar 2026 um 10:14 > An: [email protected] <[email protected]> > 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 < > [email protected] > >: > > > *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 > > >
