The following SQL commands are compared with bthash subroutine calls. bthash was not designed with SQL in mind. This comparison should help an SQL programmer to better understand bthash calls. First, SQL's relational database terminology.
SQL | Btree | Hash |
---|---|---|
Database | Group of databases | Group of databases |
Tablespace | Group of databases | Group of databases |
Table | Single database | Single database |
Row | Record | Record |
Column | Field in structure | Field in structure |
Key | Key | Key |
Attribute | Data field | Data field |
Secondary index | Separate database | Separate database |
Create file | btinit | hinit |
Primary key | Keylen and keyofst | Keylen and keyofst |
Foreign key | Separate database call | Separate database call |
Field list | C structure | C structure |
Create an Instance | btopen | hopen |
Delete an Instance | btclose | hclose |
Select where | btget | hget |
Like | btgetnxt or logic | Program logic |
Order by | btgetnxt or logic | Program logic |
Order by descending | btgetprv or logic | Program logic |
Embedded selects | Separate database call | Separate database call |
Insert | btisrt | hisrt |
Update | btupdt | hupdt |
Delete | btdlet | hdlet |
An SQL system does much more when creating an instance of a database than bthash does opening a database. The SQL system is a server with many users accessing the database at the same time. bthash is single threaded during database updates. It doesn't have to perform as many tasks to open a database.
In the section on select, the btree choices are a set of alternatives. These alternatives depend on whether the where clause refers to a key field or a data field. Good database design calls for the use of key fields wherever possible.
A feature in SQL may appear on the surface to be a very simple solution to a problem, but have an underlying cost in performance. An index in SQL may seem like a simple solution on the surface, but in reality, it has the same overhead in performance as a separate database call in bthash.
Similar examples may be given with
In bthash, you are more likely to be aware of the performance cost of a feature because of the extra program logic required. In SQL, you are less likely to be aware of the performance cost because of the simple syntax of the language and its ease of use.
The following features in SQL are done through programming logic in bthash.
The following features may or may not be available through DBA software packages for SQL.
Security is both a benefit and a bane in any organization. Corporations spend money on security when the risks outweigh the cost. Many corporations cut corners on security because of its high cost.
The security in bthash is only what the operating system provides. The security with most SQL database systems is an extra layer above what the operating system provides. This is both a benefit and a bane, because programmers are less productive under tight security. bthash is designed as a local database solution, where security is a local issue. The source code is available through distribution channels. There is no mystery about how to access or modify data. Ultimately, the programmer has the option of encrypting the data.
bthash databases are designed to be portable. This means that the wrong person can copy a bthash database to a different platform, and the database will be just as usable as before. That different platform could easily be a PDA, so the wrong person could easily copy the database to a PDA and walk out the door. This is a nightmare for security but a big benefit for the programmer, who wants to be flexible and wants the user to be flexible.