US20130013648A1 - Method for database storage of a table with plural schemas - Google Patents

Method for database storage of a table with plural schemas Download PDF

Info

Publication number
US20130013648A1
US20130013648A1 US13/635,541 US201013635541A US2013013648A1 US 20130013648 A1 US20130013648 A1 US 20130013648A1 US 201013635541 A US201013635541 A US 201013635541A US 2013013648 A1 US2013013648 A1 US 2013013648A1
Authority
US
United States
Prior art keywords
data
record
schema
records
schemas
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Abandoned
Application number
US13/635,541
Other languages
English (en)
Inventor
Miguel Angel Monjas Llorente
Gabriel Huecas
Alberto Mozo
Juan Quemada
Joaquin Salvachua
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Telefonaktiebolaget LM Ericsson AB
Original Assignee
Telefonaktiebolaget LM Ericsson AB
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Telefonaktiebolaget LM Ericsson AB filed Critical Telefonaktiebolaget LM Ericsson AB
Publication of US20130013648A1 publication Critical patent/US20130013648A1/en
Abandoned legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24—Querying
    • G06F16/245—Query processing
    • G06F16/2455—Query execution
    • G06F16/24553—Query execution of query operations
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/21—Design, administration or maintenance of databases
    • G06F16/211—Schema design and management
    • G06F16/213—Schema design and management with details for schema evolution support

Definitions

  • the present invention relates to methods of storing data in a database and more particularly to methods of storing data in a database where a table in the database is associated with a plurality of schemas defining respective sets of fields associated with the table.
  • data is stored in one or more structured collections of data collectively referred to as a database.
  • a Database Management System In order to manage the large quantities of data stored in modern databases, it is common to use a Database Management System to facilitate the creation and maintenance of a database.
  • a common type of database is a relational database.
  • a relational database represents data as a collection of relations. Each relation comprises a plurality of tuples, each tuple providing values for common attributes. Relations are logically represented by table organized into rows and columns. Each row of a table represents a tuple of a relation and each column represents an attribute of that relation.
  • Tuples are stored in a computer system as “records”. Each tuple attribute value is represented by a sequence of bytes within a record, referred to as a field.
  • Relational Database Management Systems execute query operations provided by a user application. Query operations are executed on database records stored in a main memory of the computer. Due to the need for rapid access to data, main memory is generally provided by Random Access Memory (RAM). While providing the requisite fast access times, the types of RAM commonly used to provide main memory are volatile storage technologies, requiring power to store information. Further, the relatively high cost of RAM means that, for reasonably large databases, the main memory is insufficiently large to store all records of all tables of a database.
  • RAM Random Access Memory
  • database tables are also stored in a secondary memory, generally provided by slower but higher capacity, non volatile, storage devices such as hard disk drives.
  • main memory Where it is desired to read or modify a record of a database, it is first determined whether that record is present in main memory. If a particular record is not present in main memory, it is located in secondary memory and copied to main memory for processing. Where main memory has insufficient free space to store an additional record copied from secondary memory, it is necessary to determine which of the records stored in main memory should be ejected to create space to store the additional record copied from the secondary memory. If the record chosen for ejection from main memory has been modified whilst in main memory, the modified record is copied back to secondary memory in order to ensure that changes are not lost when the record is ejected from main memory.
  • Data is stored in memory in collections of eight bits, each of which is called a byte.
  • Disks are logically arranged into fixed size groups of a particular number of bytes, generally known as “blocks”. Operations to read data from and write data to a disk are collectively known as I/O operations, and it is generally more efficient to read and write a whole number of blocks in each I/O operation.
  • Records included in tables of a database are stored in groups called pages. Often, the size of the pages of a database is selected to match the block size of a hard disk on which the database is stored. In this way, when records of a database are copied between the hard disk and the main memory in whole pages, rather than individual records, efficiency of record transfer between the main and secondary memory can be maximised. That is, when a particular record is required, the page containing that record is copied from the secondary memory to the main memory. If the record is modified, the whole page (including the modification) is copied from the main memory to the secondary memory.
  • a common approach to database management defines a fixed structure for records associated with a particular table by defining a schema for each table before any data is added to the database.
  • Such a schema defines a number of fields for which each record provides values and further defines a data type for each field and other like information.
  • a method of storing data in a database the database defining a table and the data comprising a plurality of records, each record comprising values for at least one field.
  • the method comprises storing a plurality of schemas, each schema defining a respective set of fields associated with said table, and associating each of said records with identification data identifying one of said schemas.
  • Storing a plurality of schemas defining respective sets of fields associated with a particular table is advantageous in that different records associated with the particular table need not share the same schema. It may be the case that initially, records of the particular table are defined using a first schema, but it is later desired to define a second schema which is to be used to define further records of the particular table. By using the method described above, records defined before the second schema is created can continue to be defined according to the first schema. This provides for the addition of new records, being associated with a new schema, to a table without the need to update data already stored in the table.
  • the task of updating of the structure of a table is rendered independent of the task of updating the structure of data already associated with said table, which negates the need to perform large scale batch updates of data in a database upon changing the structure of a database table.
  • This provides a number of advantages including a shortening of the time taken to perform an update process.
  • Each of said schemas may have an associated schema identifier, and the identification data may comprise a schema identifier.
  • each schema may have an associated version number, thereby allowing easy differentiation between different schemas for a particular table.
  • the plurality of schemas may be stored in a data dictionary of said database.
  • the data dictionary is sometimes referred to as a system catalog and the terms data dictionary and system catalog are used analogously herein.
  • a data dictionary typically contains information about the tables of the database, and may include data indicating table names, index names and integrity constraints on the data in addition to schemas for the database tables.
  • the method may further comprise creating a further schema defining a further set of fields of data associated with said table and storing said further schema.
  • the method may further comprise reading one of said records and modifying identification data associated with said read record to identify another of said plurality of schemas.
  • a plurality of records may have common associated identification data. That is, a single item of identification data may be associated with a plurality of records indicating that each of said plurality of records is associated with a schema identified by said identification data.
  • said plurality records may be stored in one or more pages.
  • Associating each of said records with identification data identifying one of said schemas may comprise associating identification data with each page and storing in each page only records associated with one of said schemas identified by the identification data associated with that page. That is, a single item of identification data may be stored for each page and be associated with all records stored in that page.
  • the method may further comprise reading a first record from a first page of records, said first page of records being associated with identification data identifying a first schema, receiving update data to be used to update said first record, and storing a second record in a second page of records, said second record being based upon said first record and said update data and said second page being associated with identification data identifying a second schema.
  • Each record may be associated respective identification data identifying one of said plurality of schemas. Identification data may be stored in each record, for example in a header of each record.
  • the method may further comprise reading a record, said record being associated with identification data identifying a first schema, receiving update data to be used to update said record, and updating the said record based upon said update data and modifying identification data associated with said record to identify a second schema.
  • a first schema of said plurality of schemas may comprise a first plurality of fields and a second schema of said plurality of schemas may comprise a second plurality of fields, said second plurality of fields including said first plurality of fields and at least one further field. Said at least one further field of said second schema may be associated with at least one default value. Alternatively, the second plurality of fields may be a subset of said first plurality of fields.
  • a method of reading a record from a database the database defining a table and the data comprising a plurality of records, each record comprising a value for at least one field, the database storing a plurality of schemas, and each schema defining a respective set of fields associated with said table.
  • the method comprises reading identification data associated with said record to identify one of said schemas, and reading said at least one record based upon said identified schema. Reading a record from the database can be related to an operation from a user of said database for merely obtaining data contents of a record and/or for updating contents of said record.
  • Embodiments of the invention can be implemented in any convenient way, including by way of suitable computer programs. As such, aspects of the invention also provide a computer readable medium carrying computer readable instructions configured to carry out a method as described above when loaded into a computer apparatus.
  • processor readable instructions comprise instructions controlling the processor to carry out a method as described above.
  • FIG. 1 is a schematic illustration of a computer system configured to provide a database in accordance with an embodiment of the invention
  • FIG. 2 is a schematic illustration of structures used to implement a conventional database
  • FIG. 3 is a schematic illustration showing how the structures of FIG. 2 are modified to implement an embodiment of the invention
  • FIG. 4 is a flow chart showing processing carried out to add a schema for a table to a database implemented using the structures of FIG. 3 ;
  • FIG. 5 is a flow chart showing processing carried out to read a record from a database implemented using the structures of FIG. 3 ;
  • FIG. 6 is a flow chart showing processing carried out to store a record in a database implemented using the structures of FIG. 3 ;
  • FIG. 7 is a schematic illustration of two pages showing an update operation
  • FIG. 8 is a flow chart showing processing carried out to update a stored record
  • FIG. 9 is a schematic illustration of two schemas for a table named “Fruit”;
  • FIG. 10 is a schematic illustration of three records of the “Fruit” table.
  • FIGS. 11 and 12 are schematic illustrations of the “Fruit” table
  • FIG. 1 shows a computer 1 arranged to implement an embodiment of the invention.
  • the computer 1 comprises a main memory 2 provided by RAM and a secondary memory 3 provided by a hard disk drive.
  • a processor 4 is arranged to read and execute instructions stored in a first logical part 5 of the main memory 2 . Data manipulated by those instructions is stored in a second logical part 6 of the main memory 2 .
  • the instructions stored in the first logical part 5 of the main memory 2 control the processor 4 to copy data between the second logical part 6 of the main memory 2 and the secondary memory 3 .
  • the instructions stored in the first logical part 5 of the main memory 2 control the processing of data stored in the main memory 2 which forms part of a relational database stored in the secondary memory 3 .
  • Data of the relational database is stored in both the main memory 2 and the secondary memory 3 in the form of a plurality of pages 7 , each page comprising a predetermined quantity of data in the form of database records. Data is transferred between the secondary memory 3 and the main memory 2 in whole pages.
  • the main memory 2 is not large enough to hold all pages 7 at the same time. Secondary memory 3 is therefore used to store all of the pages 7 , and the instructions control the processor 4 to copy pages 7 from secondary memory 3 to main memory 2 when required for processing, and back to secondary memory 3 for persistent storage when no longer required in the main memory 2 .
  • FIG. 2 shows two pages 8 a and 8 b comprising records 9 .
  • Each of the pages 8 a, 8 b comprises a header 10 a, 10 b comprising a number of fields referred to as “slots” 11 .
  • Each slot stores an offset within the page where a particular record 9 is stored.
  • the use of slots 11 in this way allows records of variable length to be used, given that each slot 11 can store an offset determined by the size of the particular records within the page which precede a record referenced by a particular slot. In this way, different records may have different sizes, and in particular data associated with a particular field may occupy a different amount of space in different records.
  • each record can be conveniently identified using a record identifier (rid) comprising a page identifier and a slot identifier.
  • a record identifier comprising a page identifier and a slot identifier.
  • Record 2 shown in FIG. 2 has an rid identifying the page 8 a and Slot 2 .
  • an additional data structure called an index 12 is used.
  • the index 12 is an ordered list of record references using some record field as an ordering criterion.
  • Each database table has at least one index to allow traversal across all records of the database table.
  • the ordering criterion of the index is established using a non-null value attribute, referred to as a ‘key’, of the table.
  • key a non-null value attribute
  • a record identifier (rid) is saved in each index cell to allow access to a respective record when traversing an index.
  • the stored records 9 comprise values for each of a plurality of fields defined by a table with which the records are associated.
  • the records 9 are associated with a table 13 .
  • a schema 14 is associated with the table 13 and is stored in a data dictionary 15 (the data dictionary 15 is also sometimes referred to as a system catalog).
  • the schema 14 indicates that each record associated with the table 13 stores data values for three fields, and the schematic illustration of the table 13 shows that each record comprises three data values, one for each of the three fields.
  • the data dictionary 15 contains information about the tables of the database, and includes data indicating table names, index names and integrity constraints on the data in addition to schemas for the database tables of the type described above.
  • the data dictionary may also comprise further information such as definitions of the relations between tables of the database and user access permissions for the database.
  • FIG. 3 shows a modification of the arrangement of FIG. 2 in accordance with an embodiment of the invention.
  • the data dictionary 15 now comprises a further schema 16 .
  • Both of the first schema 14 and the second schema 16 are associated with the table 13 , but specify respective properties for the table 13 .
  • the second schema 16 includes the definition of an additional field 17 for the table 13 .
  • records of a first set of records 18 associated with the table 13 each comprise values for three fields specified by the first schema 14
  • records of a second set of records 19 associated with the table 13 each comprise values for four fields as specified by the second schema 16 .
  • the second schema 16 may only comprise a subset of the fields of the first schema 14 , thereby allowing removal of obsolete fields.
  • Each of the schemas 14 , 16 has an associated version number, allowing convenient identification of each schema. Where two schemas 14 , 16 are provided in this way, each record 9 is provided with a version number field 20 so as to identify a schema according to which the record is defined. In this way, a plurality of different schemas 14 , 16 can be provided for a single table, and records can be defined and stored according to each of the schemas. This is particularly convenient as further schemas can be added to the data dictionary 15 and records then added which use one of the further schemas, the records simply comprising data which identifies the appropriate schema.
  • FIG. 4 is a flowchart showing processing carried out to add a schema to the data dictionary 15 .
  • the method is performed by the processor 4 executing instructions stored in the first portion 5 of the main memory 2 .
  • a new schema is defined for the table 13 .
  • the new schema may for example, define an additional field for the table 13 and may specify a default value for that additional field.
  • the highest current version number for schemas associated with the table 13 is determined, and a next version number is selected for the new record schema.
  • the new schema is added to the data dictionary 15 with the appropriate version number.
  • FIG. 5 shows processing carried out to read data from the table 13 .
  • the processing is performed by the processor 4 executing instructions stored in the first portion 5 of the main memory 2 .
  • a record identifier of a desired record is obtained from the index 12 .
  • the record identifier comprises a page number and slot number within a page.
  • an attempt is made to locate a page indicated by the rid in the main memory 2 .
  • a check is made to determine whether the page indicated by the rid has been successfully located in the main memory 2 . If this is not the case, the identified page is loaded into the main memory 2 from the secondary memory 3 at step S 24 and processing passes to step S 25 . If the page is located in the main memory 2 at step S 22 , processing passes directly from step S 23 to step S 25 .
  • the record is located within the relevant page using the slot number included within the rid.
  • the version field 20 of the record is read so as to determine a schema with which the read record is associated.
  • a schema associated with the read version number is obtained from the data dictionary 15 .
  • each of the fields of the record is read in turn, using the read schema obtained at step S 27 .
  • the schema allows identification of the fields included in the record, including identification of the location of the start and end of each field, so as to enable values for each field to be read.
  • the flowchart of FIG. 6 shows processing carried out to add a record to a database.
  • the processing is performed by the processor 4 executing instructions stored in the first portion 5 of the main memory 2 .
  • a most recent version of the schema for a table with which the record is associated is obtained from the data dictionary 15 .
  • a page suitable for storage of the new record is identified.
  • the identification of a page for storage of the record will depend upon the way in which records are allocated to pages. For example, if each page stores records associated with a particular schema for a particular database table, a page storing records defined according to the relevant schema is located. The location of an appropriate page may involve copying a page from the secondary memory 2 into the main memory 3 , or may involve the creation of an entirely new page.
  • a most recently created page can be used to store the record if enough space is available in the most recently created page, otherwise a new page may be created.
  • the new record is added to the located page, and at step S 34 the schema version number associated with the schema obtained at step S 31 is written to the new record.
  • the index 12 is updated so as to indicate the existence of the new record and so as to indicate a page and slot number where the record is stored.
  • FIG. 7 shows two pages 21 a, 21 b storing database records.
  • a record 22 is to be updated.
  • the record 22 is read, and at step S 42 update data which is to be used to update the record 22 is obtained.
  • step S 43 a check is carried out to determine whether the version number associated with the record read at step S 41 references the most up to date schema for the relevant database table. If this is the case, the update data is used to update the record 22 within the page 21 a at step S 44 .
  • step S 45 a new record is created at step S 45 .
  • a new record 23 is created in the page 21 b, as the page 21 b is used to store records associated with the most up to date schema for the relevant table.
  • step S 46 data is written to the new record, based upon data read at step S 41 , the update data obtained at step S 42 and the most up to date schema for the relevant table.
  • step S 47 the version number identifying the most up to date schema is written to the record 23 .
  • the record 22 is marked as obsolete, such that a process can be run to recover space used to store the record 22 when appropriate.
  • the record 22 may be marked obsolete by writing a “tomb-stone” value to an appropriate field of the record.
  • Step S 48 Processing passes from step S 48 to step S 49 where the index 12 is updated to indicate the location at which the record is stored.
  • step S 43 even if it is determined at step S 43 that the record read at step S 41 is not associated with the most up to date version of the schema, if the update data obtained at step S 42 does not require that the schema used to define the record is updated (for example the update data does not refer to a field which is not defined by the version of the schema currently defining the record), and if the page 21 a has sufficient space to accommodate the required update, the record 22 is updated within the page 21 a, instead of the record 23 being created. This may be advantageous in some circumstances given that the need to create a new record in a new page is avoided.
  • FIGS. 9 to 12 A specific example of a database implemented using the structures and methods described above is now presented with reference to FIGS. 9 to 12 .
  • FIG. 9 shows first and second schemas 24 , 25 associated with a table named “Fruit” in a database.
  • the first schema 24 defines three fields named Name, Colour and Weight, defines column positions for each of these fields, defines a data type for each field and a default value for each field.
  • FIG. 10 shows part of a page 26 storing three records defined according to the first schema 24 .
  • the page 26 includes three slots 27 referencing three records by their offsets within the page 26 .
  • a first slot references a first record 28 which begins at an offset of zero and comprises data associated with a record in which the name field has a value “Apple”.
  • a second slot references a second record 29 which begins at an offset of thirteen and comprises data associated with a record in which the name field has a value “Strawberry”.
  • a third slot references a third record 30 which begins at an offset of thirty and comprises data associated with a record in which the name field has a value “Pineapple”.
  • the second schema 25 is created using processing described with reference to FIG. 4 . It can be seen that the second schema 25 defines the three fields discussed with reference to the first schema 24 , but additionally defines a “Scientific Name” field. When the second schema 25 has been created in this way, newly created records are associated with the second schema 25 , as described with reference to the processing of FIG. 5 . Similarly, where a record associated with the first schema 24 is updated in any way, it may be updated to reference to the second schema 25 as described with reference to FIGS. 7 and 8 .
  • the “Fruit” table comprises some records associated with the second schema 25 , and other records associated with the first schema 24 , each record identifying one of the schemas 24 , 25 .
  • FIG. 11 shows records of the “Fruit” table. It can be seen that three records 31 described with reference to FIG. 10 comprise values for the three fields defined by the first schema 24 , while a new record 32 having a Name field value of “Plum” comprises values for the four fields defined by the second schema 25 . However, it can be seen from FIG. 12 that following an update operation, the record having the Name field value of “Apple” is defined using the second schema 25 and now comprises a value for the additional field “Scientific Name”.
  • each record has an associated version number field which is used to identify a stored schema.
  • a page may comprise a version number field, and this field may be used to associate all records within the page with a particular schema version, thereby obviating the need for each record to include its own version number field.
  • all records in a particular page are associated with a common schema for a particular database table.
  • each schema may, for example, be stored as a discrete structure within the data dictionary 15 .
  • clustered index If a clustered index is implemented, then records ordered by a clustered index key can be stored sequentially in a single page to allow access to several consecutive records by accessing only that single pages.
  • the use of clustered indices is often important in a relational database because such indices provide a great performance benefits when sequentially accessing all the records contained in a database table.
  • the new record can instead be reallocated into the same page if records include a schema identifier, variable length records can be accommodated within the page and the page has sufficient free space to accommodate the new record. If there is insufficient free space within the particular page, an overflow page can be used to avoid the new record being stored in an entirely different location from its neighboring records. Such an approach allows the efficiency benefits achieved through the use of clustered indices to be maintained in embodiments of the invention.
  • Handling update operations in this way is also advantageous in that the rid (record identifier) contained in the index does not need to be updated as part of the update operation, given the record remains located in the same slot of the same page.
  • clustered indices are used, a similar procedure to that described immediately above for processing updates can be used when inserting a new record, More particularly, the new record may be inserted in a page determined by a key of the clustered index.
  • pages can store records of different lengths, records associated with different schemas can be stored within a single page, as explained above.
  • records defined with a particular table may be defined according to a plurality of schemas.
  • records defined according to a schema other than the most recently defined schema may be processed so as to update them to be defined according to the most recently defined schema. Such processing may be carried out when database load is low. In this way all records are updated such that the database table converges to be defined according to the most recently defined schema, without jeopardizing database performance.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Data Mining & Analysis (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computational Linguistics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
US13/635,541 2010-03-17 2010-03-17 Method for database storage of a table with plural schemas Abandoned US20130013648A1 (en)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/EP2010/053489 WO2011113488A1 (fr) 2010-03-17 2010-03-17 Procédé de stockage d'une table avec plusieurs schémas dans une base de données

Publications (1)

Publication Number Publication Date
US20130013648A1 true US20130013648A1 (en) 2013-01-10

Family

ID=43244975

Family Applications (1)

Application Number Title Priority Date Filing Date
US13/635,541 Abandoned US20130013648A1 (en) 2010-03-17 2010-03-17 Method for database storage of a table with plural schemas

Country Status (4)

Country Link
US (1) US20130013648A1 (fr)
EP (1) EP2548134A1 (fr)
CN (1) CN103026354A (fr)
WO (1) WO2011113488A1 (fr)

Cited By (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20160292192A1 (en) * 2015-04-06 2016-10-06 Sap Se Schema evolution in mult-tenant environment
US9542439B1 (en) * 2013-06-14 2017-01-10 Emc Corporation Simplified query language for accessing metadata
WO2017059293A1 (fr) * 2015-10-02 2017-04-06 Google Inc. Magasin de données unique à schémas multiples associés à des tables dans une mémoire de valeurs-clés
US10038559B2 (en) 2015-10-02 2018-07-31 Google Llc Signatures of updates exchanged in a binary data synchronization protocol
CN108984720A (zh) * 2018-07-10 2018-12-11 上海达梦数据库有限公司 基于列存储的数据查询方法、装置、服务器及存储介质
US10956467B1 (en) * 2016-08-22 2021-03-23 Jpmorgan Chase Bank, N.A. Method and system for implementing a query tool for unstructured data files
US11151098B2 (en) * 2015-12-17 2021-10-19 Oracle International Corporation Enabling multi-tenant access to respective isolated data sets organized using different application schemas
US11223677B2 (en) 2015-10-02 2022-01-11 Google Llc Peer-to-peer syncable storage system
US11275760B2 (en) 2014-10-28 2022-03-15 Microsoft Technology Licensing, Llc Online schema and data transformations
US11297139B2 (en) * 2015-05-29 2022-04-05 Telefonaktiebolaget Lm Ericsson (Publ) Method and apparatus for client side encoding in a data processing system

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9639568B2 (en) * 2014-05-01 2017-05-02 Aktiebolaget Skf Systems and methods for improved data structure storage
US8938414B1 (en) * 2014-06-05 2015-01-20 GoodData Corporation Data abstraction layer for interfacing with reporting systems

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9218409B2 (en) * 2002-06-04 2015-12-22 Sap Se Method for generating and using a reusable custom-defined nestable compound data type as database qualifiers
US7779039B2 (en) * 2004-04-02 2010-08-17 Salesforce.Com, Inc. Custom entities and fields in a multi-tenant database system

Cited By (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9542439B1 (en) * 2013-06-14 2017-01-10 Emc Corporation Simplified query language for accessing metadata
US11275760B2 (en) 2014-10-28 2022-03-15 Microsoft Technology Licensing, Llc Online schema and data transformations
US20160292192A1 (en) * 2015-04-06 2016-10-06 Sap Se Schema evolution in mult-tenant environment
US10078676B2 (en) * 2015-04-06 2018-09-18 Sap Se Schema evolution in multi-tenant environment
US11297139B2 (en) * 2015-05-29 2022-04-05 Telefonaktiebolaget Lm Ericsson (Publ) Method and apparatus for client side encoding in a data processing system
US10972285B2 (en) 2015-10-02 2021-04-06 Google Llc Signatures of updates exchanged in a binary data synchronization protocol
US10296608B2 (en) 2015-10-02 2019-05-21 Google Llc Single table multi-schema data store in a key value store
US11138161B2 (en) 2015-10-02 2021-10-05 Google Llc Single table multi-schema data store in a key value store
US11223677B2 (en) 2015-10-02 2022-01-11 Google Llc Peer-to-peer syncable storage system
US11240298B2 (en) 2015-10-02 2022-02-01 Google Llc Peer-to-peer syncable storage system
US10038559B2 (en) 2015-10-02 2018-07-31 Google Llc Signatures of updates exchanged in a binary data synchronization protocol
WO2017059293A1 (fr) * 2015-10-02 2017-04-06 Google Inc. Magasin de données unique à schémas multiples associés à des tables dans une mémoire de valeurs-clés
US11487719B2 (en) 2015-10-02 2022-11-01 Google Llc Single table multi-schema data store in a key value store
US11632250B2 (en) 2015-10-02 2023-04-18 Google Llc Signatures of updates exchanged in a binary data synchronization protocol
US11677820B2 (en) 2015-10-02 2023-06-13 Google Llc Peer-to-peer syncable storage system
US11151098B2 (en) * 2015-12-17 2021-10-19 Oracle International Corporation Enabling multi-tenant access to respective isolated data sets organized using different application schemas
US10956467B1 (en) * 2016-08-22 2021-03-23 Jpmorgan Chase Bank, N.A. Method and system for implementing a query tool for unstructured data files
CN108984720A (zh) * 2018-07-10 2018-12-11 上海达梦数据库有限公司 基于列存储的数据查询方法、装置、服务器及存储介质

Also Published As

Publication number Publication date
EP2548134A1 (fr) 2013-01-23
CN103026354A (zh) 2013-04-03
WO2011113488A1 (fr) 2011-09-22

Similar Documents

Publication Publication Date Title
US20130013648A1 (en) Method for database storage of a table with plural schemas
US9495398B2 (en) Index for hybrid database
US9058351B2 (en) Apparatus and method for read optimized bulk data storage
JP6025149B2 (ja) データを管理するシステムおよび方法
CN102129458B (zh) 关系型数据库的存储方法及装置
US11099771B2 (en) System and method for early removal of tombstone records in database
US20120221523A1 (en) Database Backup and Restore with Integrated Index Reorganization
US20080306990A1 (en) System for performing a redistribute transparently in a multi-node system
US7693875B2 (en) Method for searching a data page for inserting a data record
US8108431B1 (en) Two-dimensional data storage system
US10776345B2 (en) Efficiently updating a secondary index associated with a log-structured merge-tree database
US8682872B2 (en) Index page split avoidance with mass insert processing
US9043294B2 (en) Managing overflow access records in a database
US20050021924A1 (en) Memory management tile optimization
US20120317384A1 (en) Data storage method
US20090144221A1 (en) Dynamic time-dimension-dependent physical management on diverse media of very large event-recording data-store
US8073823B2 (en) Database management program
US8818953B2 (en) Method and apparatus for loading data into multi-table tablespace
US20210209087A1 (en) Reorganization of Databases by Sectioning
US7444338B1 (en) Ensuring that a database and its description are synchronized
US20240193142A1 (en) Method of processing data in a database
US9529811B2 (en) System and method for manipulating data records
CN1492363A (zh) 一种嵌入式系统的数据存放及其查找方法
US7010552B2 (en) Optimizing command execution in database systems that provide support for updatable scrollable cursors
CN111459949B (zh) 针对数据库的数据处理方法、装置及设备和索引更新方法

Legal Events

Date Code Title Description
STCB Information on status: application discontinuation

Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION