There are two main column classes implemented: Columns VDBL columns are built in a very complicated way using three classes on top of each other, making it possible that arbitrary C++ types can be stored in a column. View Table: A table which is constructed from an arbitrary view using the view's internal structure to organize the data ( vdbl::view_table).Standard Table: A table which keeps all data in memory, internally organized as STL maps ( vdbl::standard_table).It is possible to implement differently organized tables, as long as they are subclasses of the class table. Column entries of a row can be left out, if a default value for the column is specified in the table definition. When creating a new row, strict type checking is done between the row's column entries and the column type stored in the table. Every row has a row id, which is used for internal organization. In addition to the column structure, which determines the outline of the table, the table's data is organized in rows (see Section Rows). A column of a table can be accessed by specifying its name or, equivalently, its column id.
All columns within a table have a name (a std::string) and a column id, which is used for organizing the column structure of the table internally. Optionally, for each column a default value can be given (this default value may also change w.r.t.\ the evaluation context). This can be done dynamically, like modifying and removing. The type of the columns value, which can be any C++ type, is fixed upon creating the column. The definition of a table is always done by specifying its columns (see Section Columns). Tables A VDBL table consists of a number of columns and rows. This is, e.g., useful in the COCONUT project for organizing points, where some of the properties change from work node to work node, like whether the point is feasible or not. Using this mechanism, columns can change their value automatically according to the evaluation context. All views onto tables are constructed within a prespecified context (see Section Contexts).
Also, additional rows can be defined for a view, and it is even possible to join various tables into one view. These views can restrict a table to a subset of columns and/or rows. Users can construct views onto tables (see Section Views). There are access control lists (at the moment not fully implemented) for restricting the access of users to the tables on a global and a column-wise base. In addition to tables, the database knows of users. The structure is defined in such a way that SQL interfaces could be written, as well as tables which keep all their data in memory. There is a general table interface defined in class table, which defines the minimal functionality needed for implementing a VDBL table. Every table (see Section Tables) has a unique name (a std::string) and a unique table id, which is used for organizing the internal structure. It is possible to construct views onto the tables of a database.ĭatabase A VDBL database consists of a number of tables which can be dynamically constructed, changed and destroyed. Using function objects, called methods, the column values can change according to an evaluation context. It structure is designed in such a way that the in-memory structure can be mixed with standard SQL databases.ĭatabases in the VDBL consist of tables, which are constructed from columns and rows as ordinary relational databases.Ĭolumns can take arbitrary types, and their values need not be constant. It uses STL containers like map and vector to organize its internal structure. The Vienna Database Library (VDBL) is a in-memory database developed with generic programming in mind. Introduction Main Page Modules Class Hierarchy Alphabetical List Compound List File List Compound Members File Members
0 kommentar(er)
