Embedded InnoDB New Database Engine

    Oracle released Embedded InnoDB.
    More recently, the "red giant" released Embedded InnoDB , under the rather democratic GPLv2 license , not Apatch 2.0 but also passable.
    At the moment, this database is available only for 32-bit versions of Windows and Linux.
    I would not dare to download and install, at first I want to look around. Go to the dock and read. Since today at work I still have nothing to do at work. I will do a small review and translation.

    In italics below, the text from the docks will be written, in the usual font my opinion on this subject.


    This database is designed for critical applications and successfully copes with both kilobytes of data and volumes of several gigabytes.
    To access data and manage databases and transactions, special APIs are used.
    This is probably no chiba SQL, so far not so entertaining.
    Since InnoDB is an embedded engine, it is super fast.
    I already want to test this, maybe by the end of the article they will encourage me to install InnoDB and test it like that.
    The reason for the speed of this database is that it runs in the same address space as your application, and avoids expensive communication procedures as in the case of classic DBMSs.
    Hmm, something like Google Gears ??
    The important point is that this DBMS is not a relational database and as a result does not provide such high-level functions as triggers and nothing similar to SQL. InnoDB is just a low-level API set for efficiently reading / writing your data.
    Embedded InnoDB allows you to embed a data base processor in your application, without having to install any of your other DBMSs. Database operations are performed using the plugin. Which allows you to perform standard actions: insert, update, delete with ordinary relational tables and columns, and also allows you to manage transactions and retrieve data cursors.

    This DBMS allows you to:
    • Work with tables, columns and indexes.

    • Your calls are not made using SQL; you are operating with API calls.

    • Your application may be without an installer. All libraries link both dynamically and statically. All parameters have default values. All necessary files will be created. At the moment, there is no need to put down any system variables.
    • The database is handled by ACID transactions (Atomicity, Consistency, Isolation, Durability) and supports commit / rollback / savepoint operations.
    • The application returns data in the form of a classic cursor.

    • You can control transaction isolation levels, as well as lock models for both tables and cursors.

    • Able to foreign keys.

    • Does not allow changing column properties after creating a table.

    • Able to B-tree data structures.



    Download install, start the database, run any IDE.
    create a database:
    ib_err_t err = ib_database_create("test");
    create a plate: a
    CREATE TABLE T(c1 VARCHAR(32), c2 VARCHAR(32), c3 UNSIGNED INT, PK(c1, c2));
    InnoDB API will look like this: The scope of this database is primarily autonomous devices that, by definition, have no connection with the outside world, but they have the responsibility of collecting some data. It is also possible to use it on mobile devices, given that the open source application should install perfectly in android. So a comparison with Google Gears suggests itself, very similar technologies. Gears distinction for browser-based offline application apps, InnoDB for desktop. However, Google has better implemented in terms of friendliness to the user, Google can fully SQL.
    ib_trx_t ib_trx;
    ib_id_t         table_id = 0;
    ib_tbl_sch_t    ib_tbl_sch = NULL;
    ib_idx_sch_t    ib_idx_sch = NULL;
    char            table_name[IB_MAX_TABLE_NAME_LEN];

    snprintf(table_name, sizeof(table_name), "%s/%s", database_name, name);

    /* Pass a table page size of 0, ie., use default page size. */
    ib_table_schema_create(table_name, &ib_tbl_sch, IB_TBL_COMPACT, 0);

    ib_table_schema_add_col(ib_tbl_sch, "c1", IB_VARCHAR, IB_COL_NONE, 32);
    ib_table_schema_add_col(ib_tbl_sch, "c2", IB_VARCHAR, IB_COL_NONE, 32);
    ib_table_schema_add_col(ib_tbl_sch, "c3", IB_INT, IB_COL_UNSIGNED, 4);

    /* Index schema handle is "owned" by the table schema handle in this
    case and will be deleted when the table schema handle is deleted. */
    ib_table_schema_add_index(ib_tbl_sch, "PRIMARY_KEY", &ib_idx_sch);

    /* Set prefix length to 0. */
    ib_index_schema_add_col( ib_idx_sch, "c1", 0);

    /* Set prefix length to 0. */
    ib_index_schema_add_col( ib_idx_sch, "c2", 0);


    /* Create the transaction that will cover data dictionary update. */
    ib_trx = ib_trx_begin(IB_TRX_SERIALIZABLE);

    /* Lock the data dictionary in exclusive mode */

    /* Create the actual table from the schema. The table id of the new
    table will be returned in table_id. */
    ib_table_create(ib_tbl_sch, &table_id);

    /* Commit the transaction */

    /* Release the data dictionary lock. */



    The same Google code will look like this: At least 100 times more concise isn't it ?? But despite all the convenience, Google can not boast of either ACID transactions, or the built-in database recovery tools, or B-tree indexes.
    try {
                db = Factory.getInstance().createDatabase();
                db.execute("create table if not exists baseapp11 (Timestamp int)");
                db.execute("delete from baseapp11");
            } catch (GearsException e) {

    Also popular now: