REVIEW 4 major objections 6 minor 19 references
V-SQL: A View-based Two-stage Text-to-SQL Framework
T0 review · 4 major / 6 minor · reviewed 2026-08-11 · deepseek-v4-flash
Pith's one-line read V-SQL claims that replacing raw database schemas with hand-built views reduces LLM schema hallucinations in text-to-SQL, yielding execution accuracy on Bird comparable to or better than three in-context-learning baselines.
desk verdict The view-based schema idea is genuinely new, but the reported results are invalid because the views were hand-fit to the test set's ground-truth joins. read the letter →
The pith
A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.
The reading
What carries the argument
The machinery is the view-based schema: a SQL view definition that flattens foreign-key chains into a single virtual table with descriptive column names, such as v_superhero exposing eye_colour, hair_colour, gender, and publisher_name. It is paired with a two-stage pipeline in which the LLM first writes dummy SQL using only views, then rewrites that dummy SQL into original-table SQL guided by the relevant mapping rules. The view acts as a compressed intermediate representation that removes join decisions from the first reasoning step, while the reconstruction stage supplies join logic explicitly from the view definition.
What would settle it
Run V-SQL on the same Bird mini-dev test set with views generated automatically from the schema alone, or from a held-out training split, and compare execution accuracy with the manually designed views; if automatic views do not beat the raw-schema baseline, the claim that view-based schemas reduce hallucinations is unsupported.
Extended reading notes
Core claim
The paper claims that simplifying how the schema is presented, rather than improving schema linking, is what lowers hallucination in LLM text-to-SQL. It maps several foreign-key-linked tables into a single denormalized view, so a query such as listing female superheroes published by Dark Horse Comics can be answered against one virtual table instead of four joined tables. The first stage generates a concise dummy SQL over views; the second stage expands that dummy SQL into final SQL using the view creation rules. Reported execution accuracy on the Bird mini-dev split is 56.0 with GPT-4, 52.8 with GPT-4-turbo, and 45.4 with GPT-3.5-turbo, which is comparable to or better than the TA-SQL, DAIL-SQL, and DIN-SQL baselines under the same no-self-consistency setting.
Load-bearing premise
The evaluation assumes it is legitimate to design the views by looking at the join operations in the ground-truth SQL of the test set; if views must instead be created from the schema alone, the reported accuracy may not hold.
Editorial extensions
If this is right
- If the central claim holds, LLM text-to-SQL accuracy can be improved without retraining or fine-tuning, purely by changing how the database schema is presented to the model.
- Smaller and cheaper models gain the most, so the view strategy could narrow the accuracy gap between large and small LLMs on join-heavy questions.
- Token cost per query should fall in the first stage because dummy SQL is shorter than final SQL, making the framework cheaper per attempt.
- The two-stage design is modular: improvements in view design or reconstruction prompts can be swapped in without changing the underlying model.
Reading between the lines
- An implication the paper leaves implicit is that the reported results probably depend on the views being hand-designed from ground-truth joins; a fair practical test would generate views from schema statistics or from a separate training split.
- Because the view idea is essentially denormalization, it may transfer to enterprise settings where common join patterns are already known from query logs or database administration practice.
- A testable extension is to measure whether the accuracy gain comes from fewer join errors in stage one or from simpler prompts overall, by ablating the reconstruction stage and inspecting failure modes.
- A second-stage failure analysis would reveal whether errors are merely displaced rather than eliminated, since the final SQL still has to reconstruct the very joins the views hid.
Editorial analysis
A structured set of objections, weighed in public.
Referee Report
Summary. The paper proposes V-SQL, a two-stage text-to-SQL framework that first maps database tables into simplified views, then has an LLM generate a short 'dummy SQL' against the views, and finally reconstructs an executable SQL query over the original tables. The authors report execution accuracy (EX) on a 500-question subset of the BIRD development set, comparing V-SQL with DIN-SQL, DAIL-SQL, and TA-SQL under GPT-4, GPT-4-turbo, and GPT-3.5-turbo. They report competitive or slightly better EX than TA-SQL on two of the three backbones, and claim the view-based schema reduces LLM schema-based hallucinations.
Significance. If the view-based schema strategy were validated in a leakage-free manner, it would be a simple and potentially useful way to reduce schema complexity for LLM-based text-to-SQL systems. The paper's central idea is clearly presented, the two-stage decomposition is easy to follow, and the appendix provides prompt templates and a worked example. These strengths are real but conditional: the empirical claim is the paper's main contribution, and that claim is undermined by the evaluation design, as detailed below.
major comments (4)
- [6. Discussion] The view definitions are explicitly fitted to the test set's ground-truth SQL. Section 6 states: 'we referred to the join operations in the ground truth SQL from the dataset and manually designed the view creation syntax.' Because the test set is a subset of the BIRD development set for which gold SQL is available, the views are constructed using information from the very queries being evaluated. This is test-set leakage, and it means the EX numbers in Table 3 do not measure the effectiveness of an independent schema-simplification method. The manual view design removes exactly the schema-linking and join-comprehension difficulty that V-SQL is supposed to solve, so the central performance claim is unsupported as reported.
- [4.3 and 7. Conclusion] The method described in Section 4.3 is an LLM-based table-mapping prompt that automatically creates view syntax (Figure 2), but the experiments evaluate manually designed views, not this prompt. The Conclusion explicitly lists automatic mapping as future work. This discrepancy is not a minor implementation detail: it means the evaluated system is a manual procedure fit to the test data, while the actually proposed framework is the automatic procedure. The paper should evaluate the automatic mapping on a validation split disjoint from the test set, or clearly reframe the contribution as a manual view-design strategy with its own validation protocol.
- [5.2, Table 3] There are no ablations isolating the contribution of the view-based schema. Table 3 only compares the end-to-end V-SQL system against end-to-end baselines. Without an ablation that keeps the two-stage reconstruction but removes the view representation, or that compares automatic versus manual views, or that varies the view granularity, the reported gains cannot be attributed to the view strategy. Given the leakage in the view design, an ablation is especially necessary to establish that any apparent gain comes from schema simplification rather than from information about the gold joins.
- [5.1 and 5.2] The evaluation lacks statistical and reproducibility details. The test set covers only 11 databases and 500 questions, and the reported differences over TA-SQL are small (for example, 52.8 versus 50.16 for GPT-4-turbo, and 45.4 versus 43.8 for GPT-3.5-turbo), yet no error bars, significance tests, or per-database breakdowns are provided. The paper also does not report the exact view definitions used, the precise prompt versions used in the actual runs, or any code or data release. These omissions are load-bearing because the main claim rests entirely on these aggregate numbers.
minor comments (6)
- [5 (heading)] The subsection titled '4.3 Fine-grained Case Study' appears after Section 5.2 and should be renumbered (e.g., 5.3).
- [Table 3] The rows labeled 'V-SQLG' should be labeled 'V-SQL' consistently with the rest of the paper.
- [Throughout] The phrase 'the Bird datasets' is grammatically awkward; the proper name is the BIRD dataset (or BIRD).
- [Figure 5] There is a typo in the prompt: 'foramt' should be 'format'.
- [Table 4] The final SQL in the 'output of the second stage' is missing a closing backtick and a semicolon, which makes the example harder to read.
- [4.1] The claim that the view-based strategy 'eliminate[s] foreign key dependencies' is imprecise: the view creation SQL still contains joins, and the foreign keys remain in the underlying tables. What is actually eliminated is the need for the LLM to write those joins when querying the view.
Circularity Check
Reported V-SQL gains rest on views manually designed from ground-truth SQL joins of the test set, so Table 3 does not independently validate the view-based strategy.
-
fitted input called prediction
[Section 6 (Discussion), with the evaluated setting described in Section 5.1 and results in Table 3; the Conclusion also acknowledges the manual design.]
"Hence, in this experiment, we referred to the join operations in the ground truth SQL from the dataset and manually designed the view creation syntax."
The view creation syntax is the central input D' to V-SQL: it defines the simplified schema from which the dummy SQL is generated (Sections 4.3 and 4.4). Designing these views from the join operations appearing in the ground-truth SQL of the same test set means the test answers are used to construct the method's schema. The EX numbers in Table 3 therefore do not measure an independent view-based schema effect; they partly measure how well the manually designed views encode the gold queries' join patterns. The Conclusion confirms the design is manual and automatic mapping is future work, so the evaluated system includes this test-fit component. This is a fitted input called prediction: the target answers are baked into the method before the method is evaluated on those answers.
full rationale
The paper's central claim is that V-SQL's view-based schema yields competitive execution accuracy on Bird. The Discussion explicitly states that the view creation syntax was manually designed using the join operations in the ground-truth SQL from the dataset, and the Conclusion confirms that automatic generation of table mappings remains future work. Because the same 500-question test set is used for both designing the views and reporting EX in Table 3, the view definitions are effectively fit to the test answers. This removes, by construction, part of the schema-linking and join-comprehension difficulty that V-SQL is claimed to solve, so the reported numbers cannot be read as independent evidence for the framework. No ablation, released view definitions, or automatic-mapping variant is provided to isolate the contribution of the view strategy. The score is 6 rather than higher because the method still requires the LLM to generate dummy SQL and reconstruct final SQL, so the prediction is not entirely forced; however, the core schema-simplification contribution is test-fit and therefore partially circular. No other significant circularity was found: the comparisons to DIN-SQL, DAIL-SQL, and TA-SQL are external and the prompting details are stated, but the main evaluation validity issue dominates.
Assumptions & free parameters
free parameters (1)
- View definitions for the 11 test databases (e.g., v_superhero) =
Left-join paths such as superhero.eye_colour_id = colour.id, chosen from the gold SQL join operations in the test set…
assumptions (3)
- domain assumption LLM hallucinations in text-to-SQL are substantially caused by foreign-key complexity and are reduced when the schema is simplified into views.
- ad hoc to paper Views built from ground-truth join operations are a fair proxy for the view-based schema strategy as it would be deployed.
- domain assumption Execution accuracy on a 500-question hand-picked subset of the Bird dev set is a stable and representative evaluation.
Cite this review
Pith. "Pith review of V-SQL: A View-based Two-stage Text-to-SQL Framework." pith.science (2026). https://pith.science/paper/WMNP2GEY
@misc{pith2026250215686,
author = {Pith},
title = {Pith review of: V-SQL: A View-based Two-stage Text-to-SQL Framework},
year = {2026},
howpublished = {\url{https://pith.science/paper/WMNP2GEY}},
note = {Machine review of arXiv:2502.15686}
}
read the original abstract
The text-to-SQL task aims to convert natural language into Structured Query Language (SQL) without bias. Recently, text-to-SQL methods based on large language models (LLMs) have garnered significant attention. The core of mainstream text-to-SQL frameworks is schema linking, which aligns user queries with relevant tables and columns in the database. Previous methods focused on schema linking while neglecting to enhance LLMs' understanding of database schema. The complex coupling relationships between tables in the database constrain the SQL generation capabilities of LLMs. To tackle this issue, this paper proposes a simple yet effective strategy called view-based schema. This strategy aids LLMs in understanding the database schema by decoupling tightly coupled tables into low-coupling views. We then introduce V-SQL, a view-based two-stage text-to-SQL framework. V-SQL involves the view-based schema strategy to enhance LLMs' understanding of database schema. Results on the authoritative datasets Bird indicate that V-SQL achieves competitive performance compared to existing state-of-the-art methods.
Reference graph
Works this paper leans on
-
[1]
arXiv preprint arXiv:2406.08426, 2024
Hong, Z., et al., Next-Generation Database Interfaces: A Survey of LLM-based Text-to-SQL. arXiv preprint arXiv:2406.08426, 2024
arXiv 2024
-
[2]
Qu, G., et al. Before Generation, Align it! A Novel and Effective Strategy for Mitigating Hallucinations in Text-to-SQL Generation
-
[3]
Proceedings of the ACM on Management of Data, 2024
Li, H., et al., Codes: Towards building open- source language models for text-to-sql. Proceedings of the ACM on Management of Data, 2024. 2(3): p. 1-28
work page 2024
-
[4]
arXiv preprint arXiv:2403.09732, 2024
Li, Z., et al., PET-SQL: A Prompt-enhanced Two-stage Text-to-SQL Framework with Cross- consistency. arXiv preprint arXiv:2403.09732, 2024
arXiv 2024
-
[5]
Pourreza, M. and D. Rafiei, DIN-SQL: decomposed in-context learning of text-to-SQL with self-correction, in Proceedings of the 37th International Conference on Neural Information Processing Systems. 2024, Curran Associates Inc.: New Orleans, LA, USA. p. Article 1577
work page 2024
-
[6]
arXiv preprint arXiv:2308.15363, 2023
Gao, D., et al., Text-to-sql empowered by large language models: A benchmark evaluation. arXiv preprint arXiv:2308.15363, 2023
arXiv 2023
-
[7]
Advances in neural information processing systems, 2022
Ouyang, L., et al., Training language models to follow instructions with human feedback. Advances in neural information processing systems, 2022. 35: p. 27730- 27744
work page 2022
-
[8]
arXiv preprint arXiv:2303.08774, 2023
Achiam, J., et al., Gpt-4 technical report. arXiv preprint arXiv:2303.08774, 2023. Appendix A Figure 2 Prompt template for view creation in the table mapping module # task You are a professional database administrator. I need to create views based on db schema to eliminate foreign keys as much as possible. Please tell me the SQL without explanation. notice:
arXiv 2023
Show all 19 references
-
[10]
All views start with "v_"
-
[11]
View don't select other view, use original table only
-
[12]
question
try to merge relevant tables in order to reduce the frequency of using join # db schema {db_description} # format example ```sql your sql ``` Figure 3 An example of view creation in the table mapping module. After the table undergoes the table mapping operation, fields like ge...
-
[13]
Do not alias the output fields
-
[14]
For example, use `table_name.column_name` instead of just `column_name`
must avoid ambiguous column name by using table name and column name in the SQL statement. For example, use `table_name.column_name` instead of just `column_name`
-
[15]
relevant db schema
refer to "relevant db schema" # relevant db schema {relevant_db_schema} # question {query} Figure 5 The prompt of the SQL reconstruction module in the second stage of V-SQL. # target According to the "views schemas", "view query" and "relevant table schemas", restore the sql i...
-
[16]
SQL should contain "join" as little as possible
-
[17]
views schemas
table in "views schemas" should not be contained in output
-
[18]
comply with the syntax of {db_type}
-
[19]
For example, use `table_name.column_name` instead of just `column_name`
must avoid ambiguous column name by using table name and column name in the SQL statement. For example, use `table_name.column_name` instead of just `column_name`. # view schemas {view_schemas} # view query Question: {query} ```sql {dummy_sql} ``` # relevant table schemas {tab...
-
[2024]
Bangkok, Thailand and virtual meeting: Association for Computational Linguistics
Reviewed August 11, 2026 · model on record in the stance chip above.
Discussion (0). Continue with ORCID to comment.