Abstract: Methods for asynchronously determining relational data integrity using cryptographic data structures are performed by systems and devices. Changes in current tables of relational databases are reflected in associated history tables. Cryptographic hybrid blockchain ledgers are updated with transaction records, for entry changes in current and history tables, including transaction information and hash values of corresponding entry changes. Hybrid blockchain ledgers also include root hash values of Merkle trees of transaction records in current blocks, and hash values of prior blocks. A current block receipt is asynchronously generated and provided as a single hash value from which the validity states of the tables and ledger are able to be verified. Cryptographic receipts of specific transactions reflected in table entry changes are generated and provide immutable evidence of specific transaction existence for users.

Abstract: Methods for asynchronously determining relational data integrity using cryptographic data structures are performed by systems and devices. Changes in current tables of relational databases are reflected in associated history tables. Cryptographic hybrid blockchain ledgers are updated with transaction records, for entry changes in current and history tables, including transaction information and hash values of corresponding entry changes. Hybrid blockchain ledgers also include root hash values of Merkle trees of transaction records in current blocks, and hash values of prior blocks. A current block receipt is asynchronously generated and provided as a single hash value from which the validity states of the tables and ledger are able to be verified. Cryptographic receipts of specific transactions reflected in table entry changes are generated and provide immutable evidence of specific transaction existence for users.

Abstract: Methods for asynchronously determining relational data integrity using cryptographic data structures are performed by systems and devices. Changes in current tables of relational databases are reflected in associated history tables. Cryptographic hybrid blockchain ledgers are updated with transaction records, for entry changes in current and history tables, including transaction information and hash values of corresponding entry changes. Hybrid blockchain ledgers also include root hash values of Merkle trees of transaction records in current blocks, and hash values of prior blocks. A current block receipt is asynchronously generated and provided as a single hash value from which the validity states of the tables and ledger are able to be verified. Cryptographic receipts of specific transactions reflected in table entry changes are generated and provide immutable evidence of specific transaction existence for users.

Abstract: Database management systems allow modification of existing table rows through update statements or other data modification commands. For example, a user may specify, via a command statement, the table to update, the columns to modify and their respective new value(s), and qualify the rows to be updated. Optimized constraint and index maintenance for data modification statements and commands is provided where the new value being assigned to the columns is actually the same as the current value, e.g., update commands that actually leave the columns unchanged.

Abstract: Implementations of various technologies for compiling a query. In one implementation, the memory consumption of the query may be monitored. If the amount of memory consumed by the query exceeds one or more gateway thresholds, then the query may be processed to acquire one or more gateways. The query may then be compiled as having acquired the one or more gateways.

Abstract: Efficient hierarchical searching is based on object type. By pre-computing additional information and storing it in a fast-lookup structure, it is possible to quickly identify objects that satisfy an object retrieval request. Furthermore, it is also possible to use this technique to avoid object hydration for operations in the store. Moreover, it is possible to leverage database statistical structures such as histograms to estimate the number of qualifying objects without having to examine each object.

Abstract: Efficient hierarchical searching is based on object type. By pre-computing additional information and storing it in a fast-lookup structure, it is possible to quickly identify objects that satisfy an object retrieval request. Furthermore, it is also possible to use this technique to avoid object hydration for operations in the store. Moreover, it is possible to leverage database statistical structures such as histograms to estimate the number of qualifying objects without having to examine each object.

Abstract: Several embodiments of the present invention are directed to systems and methods for extending the UDT framework of an extended relational data store (ERDS) to include support for unordered collections (multisets) and ordered collection (lists). More specifically, several embodiments of the present invention use an UDT infrastructure, CLR generics, and a new UNNEST operator to create and utilize a special type abstraction for collections that is simultaneously a scalar and a relation. As a scalar, this collection type can be processed by all parts of the data store engine that understand scalars (including but not limited to the client stack) and, as a relation, this collection type is queriable like any other type of relation.

Abstract: Efficient hierarchical searching is based on object type. By pre-computing additional information and storing it in a fast-lookup structure, it is possible to quickly identify objects that satisfy an object retrieval request. Furthermore, it is also possible to use this technique to avoid object hydration for operations in the store. Moreover, it is possible to leverage database statistical structures such as histograms to estimate the number of qualifying objects without having to examine each object.

Abstract: Indexed views or materialized views are used as a secondary index on a base table with multi-valued attributes. This provides for using the index to search in the nested data. Moreover, indexing is provided on the result of an unnest operation. Indexing a view on the result of an unnesting operation provides the ability to index the contents of a nested collection. One such unnesting operation is “cross apply unnest”. This provides additional options for a query execution plan, leading to a more optimized query. A back-join is provided from the indexed view to the base table to allow fields from the base table that are not present in the indexed view to be included in a result of a query on the table which is processed using the indexed view as an access path. This provides a means of including columns in the query result that are not in the indexed view but are in the base table.

Abstract: Indexed views or materialized views are used as a secondary index on a base table with multi-valued attributes. This provides for using the index to search in the nested data. Moreover, indexing is provided on the result of an unnest operation. Indexing a view on the result of an unnesting operation provides the ability to index the contents of a nested collection. One such unnesting operation is “cross apply unnest”. This provides additional options for a query execution plan, leading to a more optimized query. A back-join is provided from the indexed view to the base table to allow fields from the base table that are not present in the indexed view to be included in a result of a query on the table which is processed using the indexed view as an access path. This provides a means of including columns in the query result that are not in the indexed view but are in the base table.

Abstract: Indexed views or materialized views are used as a secondary index on a base table with multi-valued attributes. This provides for using the index to search in the nested data. Moreover, indexing is provided on the result of an unnest operation. Indexing a view on the result of an unnesting operation provides the ability to index the contents of a nested collection. One such unnesting operation is “cross apply unnest”. This provides additional options for a query execution plan, leading to a more optimized query. A back-join is provided from the indexed view to the base table to allow fields from the base table that are not present in the indexed view to be included in a result of a query on the table which is processed using the indexed view as an access path. This provides a means of including columns in the query result that are not in the indexed view but are in the base table.

Abstract: Indexed views or materialized views are used as a secondary index on a base table with multi-valued attributes. This provides for using the index to search in the nested data. Moreover, indexing is provided on the result of an unnest operation. Indexing a view on the result of an unnesting operation provides the ability to index the contents of a nested collection. One such unnesting operation is “cross apply unnest”. This provides additional options for a query execution plan, leading to a more optimized query. A back-join is provided from the indexed view to the base table to allow fields from the base table that are not present in the indexed view to be included in a result of a query on the table which is processed using the indexed view as an access path. This provides a means of including columns in the query result that are not in the indexed view but are in the base table.