I am looking for a generic term, e.g. for a database abstraction, that includes all tabular data structures like database tables, views, tabular query results aso.

As far as I understand, 'entity' is not the proper term since this would correspond to a table but not a view or even a query. 'Result' would be counterintuitive on modifiable data structures.

Which would be the proper term in the professional environment?


6 Answers 6


A "thing with columns and rows" is a relation. This is the word Codd used in his seminal paper, starting the RDBM revolution.

A "thing that can change but retain its identity" - is an entity. A single row of a relation represents an entity when you can find a unique key representing it. If you have two non-unique columns: event and date - rows will not form entities, because changing either attribute changes the meaning of the row completely. If you add an additional column (like id) or if you make date unique, you will get rows that work as entities (no matter whether it's a view or a table, or a result of a join).

A database object is just that: a thing managed by your database server. It could be a table or a view, but it could also be a user or a stored procedure.

Result is the name for the part of the API (e.g. JDBC) that reprents your results (possibly a relation or a cursor) in some other programming environment (e.g. Java runtime).

But the truth is - in a real professional environment, anything goes. People get those words mixed up and generally don't care. Heck, I don't care.

  • It's hard to decide, since the similar answer got more upvotes. However, I think, this is a correct and the most verbose answer, clarifying all the misconception around terms used in database business. Many thanks to everybody here. Commented Mar 27, 2022 at 22:33

Postgres (and also relational algebra) calls them relations - tabular things of rows and columns that you can query from. This includes tables, views, materialised views, temporary tables, or even temporary query results.

I would avoid the term "database object" if you really mean relations only, since "database objects" would also include schemas, indexes, users, sequences, policies, column definitions, types, functions, and many more. Database objects are the objects that are manipulated with DDL, whereas (the data within) relations are manipulated with DML.


Going back to the basics, a table is a set of records. A view is a virtual table, either calculated or materialised, which means it is still just a set of records.

Table source

The Microsoft documentation uses <table_source> in the BNF to indicate any source of rows - a table or view or one of a number of table-valued functions.

Just "table" :-)

I've used this term in class for many years without confusion.

Most of the time, the people you are talking to don't understand, or care, about the difference between a table or a view. Rightly so - all they need to know is "where do I get the data to do my job?"

Just explain, "here is a list of tables, pick the one you need." Of course, you haven't named tables and views differently with some stupid tibbling, right…?

  • 3
    No, a table is not just a set of records. It's also a specification of what records can look like - that is, what columns there are, what their data types are and so on. If a table were just a set of records, all empty tables would be identical. Commented Mar 16, 2022 at 23:13
  • While I agree somewhat to your assertion that most people don't care about the difference between tables and views, I completely disagree with your judgment that this is "rightly so". Commented Mar 17, 2022 at 10:44
  • 1
    SQL has bag semantics, so tables are not sets.
    – Nayuki
    Commented Mar 17, 2022 at 20:28

How about Tabular? It implies "tabularity" which means it works like a table and has the characteristics of a table but is not necessarily a table.

  • Tables and views both have that tabular row-column structure. Only problem is tabular is an adjective not a noun. Relations are tabular so it's fine to use the word if it helps communicate your meaning. Commented Mar 17, 2022 at 0:45
  • @ConcreteGannet fortunately English is quite content for people to press-gang a word into service in a different part of speech :)
    – AakashM
    Commented Mar 18, 2022 at 9:37

From Techopedia

Database Object

A database object in a relational database is a data structure used to either store or reference data. The most common object that people interact with is the table. Other objects are indexes, stored procedures, sequences, views and many more.

When a database object is created, a new object type cannot be created because all the various object types created are restricted by the very nature, or source code, of the relational database model being used, such as Oracle, SQL Server or Access. What is being created is instances of the objects, such as a new table, an index on that table or a view on the same table.

Additional reference...

SQL Server Objects

Oracle Database Objects

  • 3
    No, as you say in your quote from Techopedia, a "database object" is anything you can store in the database metadata including indexes, stored procedures and sequences as well ass views. I think @Bergi has it right - the answer to the original question is "relation". Commented Mar 15, 2022 at 4:37

I think the top answer for the term "relation" is great, especially when talking about databases in theory. But I think isn't as fitting when talking about an actual database system implementation, in practice. The reasoning being is there's a lot of constructs that exist in an actual database system implementation and which vary across implementations that aren't discussed or covered in database theory. Examples of this may include Stored Procedures, Table Variables, Table-Valued Functions, OPENQUERY() (in the Microsoft SQL Server implementation), CTEs, Subqueries, etc.

As evident in the many discussions throughout this Post, it seems different people have different interpretations of what additional physical constructs they consider to be a relation, but database theory isn't aware of those constructs. I think OP's question is quite broad, which elicits the wide array of responses displayed here, but I think most of them are fair dependent on the context in which you want to speak in.

That being said, this is why I believe the following to also be correct answers when talking about those constructs in a physical form. When a Table exists in a database system, it is concrete, considerably it's an instance of an object like a collection object of data in a running application, here the database system being the running application. Other physically implemented constructs that can return "tabular data" (as worded by the OP), e.g. Table-Valued Functions or Table Variables can also be considered objects, when referring to them in the context of an actual database system implementation. I can talk about these constructs disjoined from the set of data (relations) they can hold / return and focus on their own existence as physical objects, if that's the context I choose to speak about them.

This is why I like Brendan's answer for the term "Database Object". I also wouldn't rule the word "entity" out either.

ORMs, such as Microsoft's Entity Framework, consider all database objects (Tables, Views, Stored Procedures, etc) as entities, I believe. This is in the context of the models that structurally represent the object (typically as a class) before it's actually instantiated.

So personally, I like to use the term entity when I'm speaking of a logical concept before instantiation of sed model, or further upstream, when a logical schema is being defined such as through a database diagram. I think entity is a good term to describe the structure of a thing without it needing to be physically realized.

But when talking about a concrete representation, such as an instance of a Table object in the application, or the concretely compiled Table in the database layer, then I think database object is a good term to use just as well.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.