Pith. sign in

REVIEW 3 major objections 5 minor 46 references

A Functional Data Model and Query Language is All You Need

T0 review · 3 major / 5 minor · reviewed 2026-08-06 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read This paper argues that modeling tuples, relations, and even databases uniformly as functions yields a query language that eliminates SQL's NULL-value, injection, and impedance-mismatch problems by design.

desk verdict A plausible vision with real substance, but the SQL-injection claim is contradicted by the paper's own proposed syntax. read the letter →

arxiv 2507.20671 v1 pith:RRS6YDCN submitted 2025-07-28 cs.DB

Jens Dittrich This is my paper · ORCID
classification cs.DB
keywords functionaldatamodelquerylanguageSQLproblemsimpedancemismatchhigher-orderfunctionsvisionpaper
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

This paper is a vision proposal: instead of keeping tuples, relations, and databases as separate abstractions, model every level as a function, and use one functional query language (FQL) across all of them. The author argues that this uniform functional data model (FDM) dissolves the root cause of SQL's long-standing problems—forcing every result into a single table—and thereby removes NULL-value workarounds, the impedance mismatch between SQL and host programming languages, and SQL injection. If the vision holds, querying and updating become equally expressive, stored data and computed data become interchangeable, and the same language constructs work on a single value, a table, a whole database, or a collection of databases. The paper presents the model and many examples but explicitly leaves implementation, optimization, and formal expressive-power proofs as future work.

What carries the argument

The machinery is the FDM function hierarchy together with the FQL operator algebra built on it. A tuple is a function $t(\mathit{attr})$ returning a value, a relation is a higher-order function $R(\mathit{key})$ returning a tuple function, a database is a function $DB(\mathit{rel\_name})$ returning a relation function, and relationship functions $RF(X_1,\ldots,X_k)\mapsto Y_{RF}$ connect any collection of functions, with boolean-valued versions acting as relationship predicates. The load-bearing move is that every FQL operator is itself a higher-order function $Op(f_{\text{in}})\mapsto f_{\text{out}}$, so all operators share one signature and can be nested freely; the paper shows this via operator 'costumes' that look like native Python function calls while being delegable to a database system.

What would settle it

A concrete test would be to implement FDM/FQL and run standard relational workloads such as TPC-H: the central claim is falsified if any relational query cannot be expressed as a composition of FQL functions, or if evaluating that composition requires asymptotically more time or space than a mainstream relational engine on the same data.

Watch

Extended reading notes

Core claim

The central claim is that the tuple/relation/database hierarchy is not a hierarchy of distinct kinds of objects but a chain of functions: a tuple function maps an attribute name to a value, a relation function maps a key to a tuple function, a database function maps a relation name to a relation function, and the same pattern continues upward. Because every granule is a function, every FQL operator has the same signature—input function, output function—so operators like filter, join, group, aggregate, set difference, and update apply uniformly at any level, including returning a whole subdatabase instead of a flattened table. The model also makes stored values and computed values indistinguishable, expresses unique constraints and indexes already in the definition of a function, and encodes foreign keys as shared domains between functions. The author frames this as a path 'to come up with a modern QL that solves (almost if not) all problems of SQL,' with the unified QL/PL space opening holistic optimization between compilers and database systems.

Load-bearing premise

The entire proposal rests on the premise that all relational data—including sets, duplicates, and partial information—can be completely and faithfully represented as functions without loss of expressive power or efficiency; the paper asserts this correspondence but provides no formal mapping, completeness proof, or performance analysis.

Editorial extensions

If this is right

  • A single FQL expression can return a subdatabase, a whole database, or a set of databases, not only a single table, because operators accept and produce functions at any granule (Figures 5–9).
  • Data change becomes as expressive as data querying: the same operator algebra that reads a function can replace it in place, so updates, deletes, and even whole-database rewrites are expressed in FQL rather than in a weaker DML (Figures 10–11).
  • SQL injection is ruled out by construction, because queries are native function calls in the host programming language, not strings assembled by the application.
  • The boundary between embedded SQL and the host language disappears, so a compiler/runtime and a DBMS can optimize one combined expression space, pushing parts to the database and keeping others in the language.
  • Stored and computed functions are indistinguishable, which means FDM already includes keys, unique constraints, indexes, and foreign keys as part of the model rather than as separate physical or semantic add-ons.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • If the uniform function view is taken literally, it points toward a common intermediate representation shared by query optimizers and programming-language compilers, allowing whole-program optimizations that span database and application code; the paper only sketches this opportunity.
  • A concrete next test would be a minimal FQL implementation on top of an existing engine that translates FDM functions into physical operators, then measuring TPC-H style workloads; the paper currently provides no performance evidence.
  • The same 'everything is a function' principle could extend beyond relational data to streams, arrays, and graphs, potentially unifying OLTP, OLAP, and streaming under one language—something the author does not develop.
  • Explicit materialization via copy() suggests a new way to reason about view maintenance and caching as decisions about where function values are frozen, but the paper does not specify the trade-offs.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

3 major / 5 minor

Summary. The paper proposes a functional data model (FDM) and an associated functional query language (FQL), arguing that this design solves (almost if not) all problems of SQL, including NULL values, impedance mismatch, SQL injection, and limited update capabilities. FDM models tuples, relations, databases, and sets of databases as functions, and FQL is described as an algebra in which operators map functions to functions. The paper sketches Python-like syntax for filters, grouping, aggregation, subdatabase construction, joins, set operations, updates, and transactions, and claims that FQL integrates natively with host programming languages and opens up holistic optimization opportunities. The paper is positioned as a vision paper; no implementation, formal semantics, or proofs are provided.

Significance. If the core claims were established, the paper could meaningfully influence the design of future query languages by highlighting concrete limitations of SQL and proposing a uniform functional abstraction. The paper correctly identifies real problems (notably the single-result-relation restriction and the impedance mismatch) and builds on prior work, including the author's own RESULTDB extension. However, the contributions are presented as accomplished results rather than as a testable vision: the definitions are informal, the examples are pseudocode, no implementation exists, and at least one advertised contribution (SQL-injection impossibility) is directly contradicted by the proposed syntax. The paper contains no machine-checked proofs, reproducible code, or parameter-free derivations that could support its claims.

major comments (3)
  1. [§4.3, Figure 4a] The textual predicate alternative contradicts contribution (10), which states that FQL makes SQL injection impossible by design. Figure 4a lists `filter("age>$foo", {foo: 42}, customers)` as one of six equivalent syntax alternatives. Since FQL operators are host-language functions, nothing prevents a developer from writing `filter("age>" + user_input, {}, customers)` or `filter(f"age>{user_input}", {}, customers)`, which is exactly the SQL-injection pattern the paper claims to eliminate. The parameterized textual predicate is safe only when the developer uses it correctly, which is the same discipline as prepared statements—an approach the paper dismisses as an afterthought. Because this is a direct internal inconsistency in one of the headline contributions, the global claim that FQL solves all listed SQL problems cannot stand as stated.
  2. [Abstract and §2.2] The claim that FDM and FQL are "much more expressive than the relational model and SQL" is asserted without the formal apparatus needed to evaluate it. Definitions 1–5 are informal: Definition 5 defines the FQL algebra merely as operands, operators, and "rules for combining them," but no such rules are specified. No formal semantics for FDM or FQL is given, no notion of expressiveness is defined, and no comparison to relational algebra, SQL, or any existing query language is proved. Since the paper's own conclusion (Section 6) states that a full-blown implementation lies ahead, there is no artifact or formal result that could substantiate the expressiveness claim. This is a load-bearing gap for a paper whose entire case rests on the superiority of the proposed model.
  3. [§4.1 and §6] The FQL operator algebra and its execution semantics are only sketched through syntax examples in Figures 4–11. There is no precise definition of operator semantics, typing of functions, or evaluation order; the paper even states that an FQL expression may be read either declaratively or as a function depending on the interpretation. The claimed benefits—holistic optimization across PL and DBMS, generalized outer joins, subdatabase operations, and in-place updates with transactional semantics—are all presented as consequences of the algebra, but without formal definitions or an implementation, these benefits cannot be verified or even tested. For a paper that aims to replace SQL, this level of informality is insufficient to support the central claims.
minor comments (5)
  1. [§3] The phrase "physiological design step" appears to be a typo; it should read "physical design step."
  2. [§5] In the paragraph on Rel, "Python wich can even be checked" should be "Python which can even be checked."
  3. [References] Reference [47] is cited as the Wikipedia article on "Function (mathematics)" but its listed title is "Linq," which is incorrect and appears to be a copy-paste error.
  4. [Figure 3 caption] The caption contains "we se a database function" and should be "we see a database function."
  5. [Definition 3] Definition 3 uses `bool` in the codomain of a relationship predicate without specifying the type system; since FQL is intended to rely on the host PL's type system, the meaning of `bool` should be clarified.

Circularity Check

0 steps flagged · score 2.0 of 10

No significant circularity: the paper asserts its vision rather than deriving predictions from fitted inputs; self-citations are inspirational, not load-bearing.

full rationale

The paper is a vision proposal rather than a derivation: Sections 2-4 define FDM (tuples, relations, databases as functions) and FQL (operators that map functions to functions), and the abstract's claims about solving SQL problems and being more expressive are asserted rather than derived from any fitted parameter or prior theorem. There is therefore no step in which a 'prediction' is equivalent by construction to its input, and no equation reduces to itself. The only self-referential elements are citations to the author's prior work ([35] on RESULTDB and [17], the predecessor RMTM report) and to [16]; these are used as motivation and contrast ('inspired by', 'product'), not as the justification of FDM/FQL's expressiveness. The conclusion explicitly lists a full implementation as future work, which is consistent with the paper being a vision statement. One in-scope inconsistency exists independently of circularity: contribution (10) claims SQL injection is 'impossible by design', yet Figure 4a shows the textual-predicate costume filter("age>$foo", {foo: 42}, customers), which permits predicates built by string concatenation from untrusted input and therefore reintroduces the classic injection pattern unless developers use parameters correctly. That is a semantic/consistency gap in a claimed solved problem, not a circular derivation, so it does not raise the circularity score. Given only minor non-load-bearing self-citations, the appropriate score is 2.

Assumptions & free parameters 0 free parameters · 4 assumptions · 3 invented entities

The paper introduces no numerical free parameters. Its load-bearing assumptions are conceptual: functions behave according to standard mathematical definitions; computed and stored data are interchangeable; the functional model matches relational expressiveness; and SQL injection is avoided by design. The last two are ad hoc to this paper and unsupported. The invented entities are the FDM abstraction, relation functions, and function costumes, none of which have independent evidence beyond the paper's own claims.

assumptions (4)
  • standard math The mathematical definition of a function (each input maps to exactly one output) carries over to data modeling and implies unique constraints (Definition 1, Section 2.4).
    Used to argue that functions model relations and provide uniqueness for free. This is a correct mathematical fact but its applicability to database semantics is assumed.
  • domain assumption A computed attribute value is indistinguishable from a stored one (Section 2.3: 'a computed attribute value may return something that was never inserted').
    Assumes that the distinction between stored and derived data is irrelevant for query semantics, which is not always true (e.g., for updates, lineage, and performance).
  • ad hoc to paper Modeling all data as functions preserves the expressive power of the relational model and can be mapped to physical storage (Section 2.2 and 3).
    This is essential for the claim that FDM can replace RM, but no formal mapping or proof is given.
  • ad hoc to paper FQL makes SQL injection impossible by design (Section 1 contribution 10).
    This is asserted without analysis of the textual predicate example in Figure 4a, where user input is substituted into a string expression, which resembles injection-prone behavior.
invented entities (3)
  • FDM (Functional Data Model)
    purpose: To replace the relational model by modeling all data as functions.
    A proposed abstraction with no implementation or formal proof of equivalence to the relational model.
  • Relation function (higher-order function from key to tuple function)
    purpose: To represent a relation as a function rather than a set of tuples.
    The paper's novel twist; no independent evidence that it preserves relational expressive power or supports efficient query processing.
  • Function costume (FQL operator embedded in host PL)
    purpose: To make QL and PL the same thing, enabling delegation to the DBMS.
    Conceptual only; no runtime or compiler support is provided.

how reviews work

0 comments
Cite this review

Pith. "Pith review of A Functional Data Model and Query Language is All You Need." pith.science (2026). https://pith.science/paper/RRS6YDCN

@misc{pith2026250720671,
  author       = {Pith},
  title        = {Pith review of: A Functional Data Model and Query Language is All You Need},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/RRS6YDCN}},
  note         = {Machine review of arXiv:2507.20671}
}
read the original abstract

We propose the vision of a functional data model (FDM) and an associated functional query language (FQL). Our proposal has far-reaching consequences: we show a path to come up with a modern QL that solves (almost if not) all problems of SQL (NULL-values, impedance mismatch, SQL injection, missing querying capabilities for updates, etc.). FDM and FQL are much more expressive than the relational model and SQL. In addition, in contrast to SQL, FQL integrates smoothly into existing programming languages. In our approach both QL and PL become the "same thing", thus opening up some interesting holistic optimization opportunities between compilers and databases. In FQL, we also do not need to force application developers to switch to unfamiliar programming paradigms (like SQL or datalog): developers can stick with the abstractions provided by their programming language.

Figures

Figures reproduced from arXiv: 2507.20671 by the authors.

Figure 1
Figure 1. Traditional entity-relationship diagram vs relation [PITH_FULL_IMAGE:figures/full_fig_p003_1.png] view at source ↗
Figure 2
Figure 2. General idea of a Relationship Function RF date name DB(rel_name) ia_accessed_by(cid,pid) users(uid) [PITH_FULL_IMAGE:figures/full_fig_p004_2.png] view at source ↗
Figure 7
Figure 7. Outer join separating outer from inner semantics [PITH_FULL_IMAGE:figures/full_fig_p005_7.png] view at source ↗
Figures from the paper (4 more)
Figure 8
Figure 8. Figure 8: Grouping sets outputting different relations per [PITH_FULL_IMAGE:figures/full_fig_p005_8.png]
Figure 4
Figure 4. Figure 4: Python FQL operator costumes alternatives, includ [PITH_FULL_IMAGE:figures/full_fig_p005_4.png]
Figure 10
Figure 10. Figure 10: inserts, updates, and deletes; note the absence of [PITH_FULL_IMAGE:figures/full_fig_p005_10.png]
Figure 11
Figure 11. Figure 11: Transactional snapshot semantics in Python using [PITH_FULL_IMAGE:figures/full_fig_p006_11.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

46 extracted references · 38 canonical work pages

  1. [1]

    Serge Abiteboul, Richard Hull, and Victor Vianu. 1995. Foundations of Databases. Addison-Wesley. http://webdam.inria.fr/Alice/

    work page 1995

  2. [3]

    DuckDB Array-syntax. 2025. DuckDB Array. https://duckdb.org/docs/stable/ sql/data_types/array. [Online; accessed 28-July-2025]

    work page 2025

  3. [4]

    Maximilian Bandle and Jana Giceva. 2021. Database Technology for the Masses: Sub-Operators as First-Class Entities.Proc. VLDB Endow.14, 11 (2021), 2483–2490

    work page 2021

  4. [5]

    David Beech. 1988. A foundation for evolution from relational to object databases. In Advances in Database Technology—EDBT ’88, J. W. Schmidt, S. Ceri, and M. Mis- sikoff (Eds.). Springer Berlin Heidelberg, Berlin, Heidelberg, 251–270

    work page 1988

  5. [6]

    Jochen Van den Bercken, Björn Blohsfeld, Jens-Peter Dittrich, Jürgen Krämer, Tobias Schäfer, Martin Schneider, and Bernhard Seeger. 2001. XXL - A Library Ap- proach to Supporting Efficient Implementations of Advanced Database Queries. In Proceedings of the 27th International Conference on Very Large Data Bases (VLDB ’01). Morgan Kaufmann Publishers Inc., ...

    work page 2001

  6. [8]

    Campbell, David W

    Douglas M. Campbell, David W. Embley, and Bogdan D. Czejdo. 1985. A Rela- tionally Complete Query Language for an Entity-Relationship Model. In Entity- Relationship Approach: The Use of ER Concept in Knowledge Representation, Pro- ceedings of the Fourth International Conference on Entity-Relationship Approach, Chicago, Illinois, USA, 29-30 October 1985 , ...

    work page 1985

  7. [9]

    Chamberlin and Raymond F

    Donald D. Chamberlin and Raymond F. Boyce. 1974. SEQUEL: A Structured English Query Language. In Proceedings of 1974 ACM-SIGMOD Workshop on Data Description, Access and Control, Ann Arbor, Michigan, USA, May 1-3, 1974, 2 Volumes, Gene Altshuler, Randall Rustin, and Bernard D. Plagman (Eds.). ACM, 249–264

    work page 1974

  8. [10]

    A. Chan, U. Dayal, and S. Fox. 1987. An Ada-compatible distributed database management system. Proc. IEEE 75, 5 (1987), 674–694. https://doi.org/10.1109/ PROC.1987.13781

    work page arXiv 1987

Show all 46 references
  1. [11]

    Peter P. Chen. 1975. The Entity-Relationship Model: Toward a Unified View of Data. In Proceedings of the International Conference on Very Large Data Bases, September 22-24, 1975, Framingham, Massachusetts, USA , Douglas S. Kerr (Ed.). ACM, 173

    1975

  2. [12]

    E. F. Codd. 1970. A Relational Model of Data for Large Shared Data Banks. Commun. ACM 13, 6 (1970), 377–387. https://doi.org/10.1145/362384.362685

    1970

  3. [13]

    E. F. Codd. 1971. Further Normalization of the Data Base Relational Model. Research Report / RJ / IBM / San Jose, California RJ909 (1971)

    1971

  4. [14]

    Czejdo, Ramez Elmasri, Marek Rusinkiewicz, and David W

    Bogdan D. Czejdo, Ramez Elmasri, Marek Rusinkiewicz, and David W. Emb- ley. 1990. A Graphical Data Manipulation Language for an Extended Entity- Relationship Model. Computer 23, 3 (1990), 26–36. https://doi.org/10.1109/2. 50270

    1990 doi

  5. [15]

    C. J. Date. 1984. A Critique of the SQL Database Language. SIGMOD Rec. 14, 3 (1984), 8–54. https://doi.org/10.1145/984549.984551

    1984

  6. [16]

    Amol Dehspande. 2025. Beyond Relations: A Case for Elevating to the Entity- Relationship Abstraction. CIDR ’25 (2025)

    2025

  7. [17]

    Jens Dittrich. 2025. How to get Rid of SQL, Relational Algebra, the Rela- tional Model, ERM, and ORMs in a Single Paper – A Thought Experiment. arXiv:2504.12953 [cs.DB] https://arxiv.org/abs/2504.12953

    2025 arXiv

  8. [18]

    Jens Dittrich and Joris Nix. 2020. The Case for Deep Query Optimisation. In 10th Conference on Innovative Data Systems Research, CIDR 2020, Amsterdam, The Netherlands, January 12-15, 2020, Online Proceedings . www.cidrdb.org

    2020

  9. [19]

    Jens-Peter Dittrich and Marcos Antonio Vaz Salles. 2006. iDM: A Unified and Versatile Data Model for Personal Dataspace Management. In VLDB. 367–378

    2006

  10. [20]

    Ramez Elmasri and Gio Wiederhold. 1981. GORDAS: A Formal High-Level Query Language for the Entity-Relationship Model. In Entity-Relationship Approach to Information Modeling and Analysis, Proceedings of the Second International Conference on the Entity-Relationship Approach (E...

    1981

  11. [21]

    Peter M. D. Gray. 2005. The Functional Approach to Data Management: Mod- elling, Analysing and Integrating Heterogeneous Data. Program 39, 4 (2005), 401. https://doi.org/10.1108/PROG.2005.39.4.401.14

    2005 doi

  12. [22]

    Peter M. D. Gray. 2018. AMOSQL. In Encyclopedia of Database Systems, Second Edition, Ling Liu and M. Tamer Özsu (Eds.). Springer. https://doi.org/10.1007/978- 1-4614-8265-9_1111

    2018 doi

  13. [23]

    Peter M. D. Gray. 2018. Functional Data Model. In Encyclopedia of Database Systems, Second Edition , Ling Liu and M. Tamer Özsu (Eds.). Springer. https: //doi.org/10.1007/978-1-4614-8265-9_173

    2018 doi

  14. [24]

    Peter M. D. Gray. 2018. Functional Query Language. In Encyclopedia of Database Systems, Second Edition , Ling Liu and M. Tamer Özsu (Eds.). Springer. https: //doi.org/10.1007/978-1-4614-8265-9_1092

    2018 doi

  15. [25]

    Alex Grönholm. 2025. Typeguard. https://github.com/agronholm/typeguard? tab=readme-ov-file. [Online; accessed 11-July-2025]

    2025

  16. [26]

    Shashank Gugnani, Zhen Hua Liu, Hui Chang, Beda Hammerschmidt, Srinivas Kareenhalli, Kishy Kumar, Tirthankar Lahiri, Ying Lu, Douglas McMahon, Ajit Mylavarapu, Sukhada Pendse, and Ananth Raghavan. 2025. JSON Relational Duality: A Revolutionary Combination of Document, Object, ...

    2025

  17. [27]

    André Kohn, Viktor Leis, and Thomas Neumann. 2021. Building Advanced SQL Analytics From Low-Level Plan Operators. In SIGMOD ’21: International Confer- ence on Management of Data, Virtual Event, China, June 20-25, 2021 , Guoliang Li, Zhanhuai Li, Stratos Idreos, and Divesh Sriv...

    2021

  18. [28]

    K. G. Kulkarni and Malcolm P. Atkinson. 1986. EFDM: Extended Functional Data Model. Comput. J. 29, 1 (1986), 38–46. https://doi.org/10.1093/COMJNL/29.1.38

    1986 doi

  19. [29]

    Linq. 2025. Linq. https://learn.microsoft.com/en-us/dotnet/csharp/linq/. [Online; accessed 1-April-2025]

    2025

  20. [30]

    Guy M. Lohman. 1988. Grammar-like Functional Rules for Representing Query Optimization Alternatives. In Proceedings of the 1988 ACM SIGMOD International Conference on Management of Data, Chicago, Illinois, USA, June 1-3, 1988 , Haran Boral and Per-Åke Larson (Eds.). ACM Press, 18–27

    1988

  21. [31]

    David Maier. 1983. The Theory of Relational Databases . Computer Science Press. http://web.cecs.pdx.edu/%7Emaier/TheoryBook/TRD.html

    1983

  22. [32]

    DuckDB Map-syntax. 2025. DuckDB Map. https://duckdb.org/docs/stable/sql/ data_types/map.html. [Online; accessed 28-July-2025]

    2025

  23. [33]

    Mitre. 2024. 2024 CWE Top 25 Most Dangerous Software Weaknesses. https: //cwe.mitre.org/top25/archive/2024/2024_cwe_top25.html. [Online; accessed 21-February-2025]

    2024

  24. [34]

    Thomas Neumann and Viktor Leis. 2024. A Critique of Modern SQL and a Proposal Towards a Simple and Expressive Query Language. In 14th Conference on Innovative Data Systems Research, CIDR 2024, Chaminade, HI, USA, January 14-17, 2024

    2024

  25. [35]

    Joris Nix and Jens Dittrich. 2025. Extending SQL to Return a Subdatabase. SIGMOD ’25 (2025)

    2025

  26. [36]

    Christopher Olston, Benjamin Reed, Utkarsh Srivastava, Ravi Kumar, and Andrew Tomkins. 2008. Pig latin: a not-so-foreign language for data processing(SIGMOD ’08). 1099–1110

    2008

  27. [37]

    Kian Win Ong, Yannis Papakonstantinou, and Romain Vernoux. 2014. The SQL++ Semi-structured Data Model and Query Language: A Capabilities Survey of SQL-on-Hadoop, NoSQL and NewSQL Databases. CoRR abs/1405.3631 (2014). arXiv:1405.3631 http://arxiv.org/abs/1405.3631

    2014 arXiv

  28. [38]

    Oracle. 2025. JSON Relational Duality. https://blogs.oracle.com/database/post/ json-relational-duality-app-dev. [Online; accessed 24-March-2025]

    2025

  29. [39]

    Christine Parent and Stefano Spaccapietra. 1984. An Entity-Relationship Algebra. In Proceedings of the First International Conference on Data Engineering, April 24-27, 1984, Los Angeles, California, USA . IEEE Computer Society, 500–507

    1984

  30. [40]

    Premerlani, James E

    William J. Premerlani, James E. Rumbaugh, Michael R. Blaha, and Thomas A. Varwig. 1990. An object-oriented relational database. Commun. ACM 33, 11 (Nov. 1990), 99–109. https://doi.org/10.1145/92755.92772

    1990

  31. [41]

    PRQL. 2025. PRQL. https://github.com/PRQL/prql. [Online; accessed 1-April- 2025]

    2025

  32. [42]

    Rel. 2025. Rel. https://docs.relational.ai/rel. [Online; accessed 2-April-2025]

    2025

  33. [43]

    David W. Shipman. 1979. The Functional Data Model and the Data Language DAPLEX (Abstract). In Proceedings of the 1979 ACM SIGMOD International Con- ference on Management of Data, Boston, Massachusetts, USA, May 30 - June 1 , Philip A. Bernstein (Ed.). ACM, 59. https://doi.org/...

    1979

  34. [44]

    Morcos, Michael 7 Shen, David Wilhite, Xi Wu, and Lulan Yu

    Jeff Shute, Shannon Bales, Matthew Brown, Jean-Daniel Browne, Brandon Dol- phin, Romit Kudtarkar, Andrey Litvinov, Jingchi Ma, John D. Morcos, Michael 7 Shen, David Wilhite, Xi Wu, and Lulan Yu. 2024. SQL has problems. We can fix them: Pipe syntax in SQL. Proc. VLDB Endow. 17,...

    2024

  35. [45]

    Alkis Simitsis, Georgia Koutrika, Yannis Alexandrakis, and Yannis Ioannidis. 2008. Synthesizing structured text from logical database subsets. In Proceedings of the 11th International Conference on Extending Database Technology: Advances in Database Technology (Nantes, France)...

    2008

  36. [46]

    Alkis Simitsis, Georgia Koutrika, and Yannis Ioannidis. 2008. Précis: from un- structured keywords as queries to structured databases as answers. The VLDB Journal 17, 1 (Jan. 2008), 117–149. https://doi.org/10.1007/s00778-007-0075-9

    2008 doi

  37. [47]

    Wikipedia. 2025. Linq. https://en.wikipedia.org/wiki/Function_(mathematics). [Online; accessed 24-July-2025]

    2025

  38. [48]

    Franklin, Scott Shenker, and Ion Stoica

    Matei Zaharia, Mosharaf Chowdhury, Tathagata Das, Ankur Dave, Justin Ma, Murphy McCauly, Michael J. Franklin, Scott Shenker, and Ion Stoica. 2012. Re- silient Distributed Datasets: A Fault-Tolerant Abstraction for In-Memory Cluster Computing. In Proceedings of the 9th USENIX S...

    2012

Pith tools

Reviewed August 6, 2026 · model on record in the stance chip above.