Shulou(Shulou.com)06/01 Report--

Have time to discuss it.

Http://blog.chinaunix.net/u/17076/showart.php?id=174108#fig1

[@ more@]

Architecture Overview and comparison

There are many differences between DB2, MySQL, and PostgreSQL. Let's first look at some differences and similarities in the basic architecture of the three database servers.

Architecture model

The MySQL database server uses an architecture based on dedicated server threads.

PostgreSQL and DB2 use a dedicated server process model architecture.

Storage engine

MySQL databases use a pluggable storage engine architecture.

PostgreSQL and DB2 use a dedicated storage engine.

Tablespace model

MySQL uses tablespaces for InnoDB and NDB storage engines.

PostgreSQL tablespaces can span multiple databases.

DB2 tablespaces are specific to a database.

Mode support

PostgreSQL and DB2 have real schema support.

MySQL does not have real schema support. Schemas in MySQL can be thought of as MySQL databases.

Whether database object names are case-sensitive

MySQL and PostgreSQL on Linux use case-sensitive database, table, and column names.

DB2 on all platforms uses case-insensitive names. However, DB2 stores names only in uppercase.

Array column

MySQL and DB2 do not support array columns.

PostgreSQL supports array columns.

Authentication

DB2 uses a variety of external security mechanisms to perform authentication, such as operating system, PAM, Kerberos, Active Directory, LDAP, and so on. It also allows the insertion of third-party security modules.

PostgreSQL performs authentication in one of many different ways. It can use database users / roles, operating systems, PAM, Kerberos, and so on, depending on the settings in the host configuration file (pg_hba.conf).

MySQL implements authentication and encrypts passwords at the database level.

Case architecture

DB2 instances manage different databases, and there can be many DB2 instances on the same machine.

The instance concept of PostgreSQL is similar to that of a database cluster.

The MySQL instance is similar to the DB2 database.

MySQL and PostgreSQL databases can make feature changes almost every week, but feature implementations and modifications in DB2 are carefully planned because so many businesses rely on using DB2 products. Note that we use MySQL 5.1, PostgreSQL 8.0.3, and DB2 V8.2 for comparison in this article, so keep this in mind when reading this article.

Figures 1, 2, and 3 are architectural diagrams of MySQL, PostgreSQL, and DB2. After reading some documentation, we tried our best to draw the architecture diagram of MySQL and PostgreSQL. If you find anything that is not in line with the actual situation, please let us know and we will correct it.

MySQL

MySQL uses a thread-based architecture, while PostgreSQL and DB2 use a process-based architecture. As you can see in figure 1, a single MySQL instance can manage many databases. All MySQL databases in an instance share a common system catalog, INFORMATION_SCHEMA.

The database in DB2 is a separate entity with its own system catalog, table space, buffer pool, and so on. DB2 instances manage different databases, but databases do not share tablespaces, logs, system catalogs, or temporary tablespaces.

A MySQL instance with many databases can be thought of as a database in DB2, and each MySQL database is equivalent to a schema in DB2. If there are several MySQL instances running on the server, and each instance manages several databases, you can use one of the following migration methods:

Migrate each MySQL instance to a DB2 database under the same DB2 instance.

Migrate each MySQL instance to a DB2 instance that contains only one DB2 database, and assign a different schema to each MySQL database.

Note: when we refer to process-based architecture, we are referring to the UNIX ®platform because the model on Windows is thread-based architecture. This is true for both DB2 and PostgreSQL.

Only one database resource can be accessed within the scope of a DB2 connection, while MySQL allows access to multiple database resources within the scope of the same connection.

One of the most interesting features of MySQL is the pluggable storage engine. You can choose the MyISAM, InnoDB, Archive, Federated, Memory, Merge, Cluster, NDB, or Custom storage engine. Each storage engine has different properties, and you can choose a storage engine according to your specific needs. For comparison, we find that InnoDB is closest to a relational database.

Figure 1. Overview of MySQL architecture and processes

The MySQL server process (mysqld) can create many threads:

A global thread (one for each server process) is responsible for creating and managing each user connection thread.

Create a thread to process each new user connection.

Each connection thread also performs authentication and queries.

On Windows, there is a named pipe processor thread that performs the same work as the connection thread for named pipe connection requests.

A signaling thread processes alerts and forces connections that have been idle for a long time to time out.

Assign a thread to handle the shutdown event.

Some threads handle synchronization between master and slave servers during replication.

Use threads to handle table refreshes, maintenance tasks, and so on.

MySQL uses data cache, record cache, key cache, table cache, hostname cache, and privileged cache to cache and retrieve different types of data used by all threads in the server process.

In addition, the MySQL main process (mysqld) has threads to handle database management activities, such as backup, recovery, concurrency control, and so on.

PostgreSQL

The PostgreSQL instance (see figure 2) can manage a database cluster. Each database has its own system catalog, INFORMATION_SCHEMA and pg_catalog. All databases share pg_databases as a common system table. Each database is a separate entity, and the collection of databases is called a cluster. A PostgreSQL instance can manage a database cluster. A server can run multiple instances.

Logically, PostgreSQL databases can be migrated to DB2 databases. Both databases support schema object types. You cannot access other databases from a named connection.

The most significant difference between PostgreSQL and DB2 is related to tablespaces. PostgreSQL tablespaces can span multiple databases, while DB2 tablespaces are specific to one database.

Figure 2. Overview of PostgreSQL architecture and processes

A PostgreSQL session consists of several main processes:

The postmaster process is a supervisor process that generates other processes and listens for user connections.

User processes, such as psql, are used to handle interactive SQL queries.

Postmaster generates one or more server processes named postgres to process the user's data requests.

Server processes communicate with each other through semaphores and shared memory.

DB2

Figure 3 shows the architecture of DB2. This figure illustrates how DB2 uses buffer pools to process data (files, raw devices, directories, and so on) between disks. DB2 uses a connection concentrator to handle a large number of connections. The DB2 page cleaner and prefetcher work asynchronously, and each process handles the redo log activity separately. For a detailed description of how locks and processes work in DB2, see Resources.

Figure 3. Overview of DB2 architecture and processes

A DB2 session consists of several processes:

What is the difference between MySQL, PostgreSQL, and DB2?

MySQL uses a thread-based architecture model, while PostgreSQL and DB2 use a process-based architecture model.

DB2 can have multiple instances on one server. There can be many databases in each instance. Each database is physically and logically isolated from other databases.

MySQL can run multiple mysqld instances on a single server. Each instance can manage one or more MySQL databases. Each database in an instance is not physically or logically isolated. Each database in MySQL can be thought of as a schema in DB2.

You can think of a PostgreSQL database cluster as equivalent to an DB2 instance.

Db2sysc, the main DB2 system controller, the engine process.

Listener processes, such as db2tcpcm and db2ipccm, listen for user connection requests.

One or more agents that represent the work of the application. There are two types of agents:

Db2agent works on behalf of an application and communicates with other agents using interprocess communication or remote communication protocols.

Db2agntp is used to satisfy client requests to the database with internal parallelism turned on.

The user's process, such as db2, is used to handle interactive queries from the command line.

Db2bp-A persistent background process for DB2 Command Line Processor (CLP).

Db2disp-an agent scheduler process that is used to assign connections to available collaboration agents with connection concentrator enabled.

Db2fmcd-- the failure monitor collaboration daemon for each server.

Db2fmd-- the fault monitor daemon for each instance.

Db2resyn-A resynchronization manager process for handling two-phase commits.

Db2dlock-an DB2 deadlock detector.

Db2loggr-database log reader.

Db2loggw-database log writer.

Db2pclnr-buffer pool page cleaner.

Db2pfchr-buffer pool prefetcher.

Db2fmp-used to run user code outside the DB2 address space on the server.

Wait

DB2 server processes communicate with each other through memory areas called database manager memory (Database Manager Memory) and database shared memory (Database Shared Memory), as shown in figure 4.

Figure 4. DB2 database manager (instance) and database shared memory architecture

Characteristic comparison

Table 1 compares MySQL, PostgreSQL, and DB2 features. This is not a complete list, but it compares the most commonly used features.

Table 1. Comparison of MySQL, PostgreSQL and DB2 features

Characteristics

MySQL

PostgreSQL

DB2

Example

Start the instance by executing the MySQL command (mysqld). An instance can manage one or more databases. A server can run multiple mysqld instances. An instance manager can monitor individual instances of mysqld.

Start the instance by executing the Postmaster process (pg_ctl). An instance can manage one or more databases that form a cluster. A cluster is an area on disk that is initialized at installation time and consists of a directory in which all data is stored. Create the first database using initdb.

An instance is an DB2 installation that manages one or more databases. Create a default instance during installation. Use the db2start command to start the instance. You can also use the db2icrt command to create multiple instances on the same machine. The data store is not allocated until the database itself is created. The database can use the original device to manage the storage itself, or use the operating system file system. The environment variable DB2INSTANCE determines which instance to connect to.

Database

A database is a named collection of objects, entities that are separate from other databases in the instance. All databases in an MySQL instance share the same system catalog.

A database is a named collection of objects, and each database is an entity separate from other databases. Each database has its own system catalog, but all databases share pg_databases.

A database is a named collection of objects and entities separate from other databases. Databases are physically and logically independent entities that do not share anything with other databases. A DB2 instance can manage one or more databases.

Data buffer

Set the data buffer through the innodb_buffer_pool_size configuration parameter. This parameter is the number of bytes in the memory buffer that InnoDB uses to cache table data and indexes. On a dedicated database server, this parameter can be set to up to 80% of the machine's physical memory.

Shared_buffers cache. 64 buffers are allocated by default. The default block size is 8K. You can update the buffer cache by setting the shared_buffers parameter in the postgresql.conf file.

One buffer pool is allocated by default, and other buffer pools can be added using the CREATE BUFFERPOOL command. The default page size is determined when the database is created and can be 4, 8, 16, or 32K.

Database connection

When the client connects to the database using CONNECT or USE statements, you can specify the database name, as well as the user id and password. Use roles to manage users and user groups in the database.

When the client connects to the database using the connect statement, you can specify the database name, as well as the user id and password. Use roles to manage users and user groups in the database.

When the client connects to the database using the connect statement, you can specify the database name, as well as the user id and password. Use operating system commands to create users and user groups outside the database.

Authentication

MySQL manages authentication at the database level.

Authentication for PostgreSQL depends on the host configuration.

DB2 uses API to authenticate users at the operating system level through various implementations such as Kerberos, LDAP, Active Directory, and PAM, and its pluggable authentication architecture allows for the insertion of third-party modules.

Encrypt

You can specify a password at the table level to encrypt the data. You can also use the AES_ENCRYPT and AES_DECRYPT functions to encrypt and decrypt column data. Network encryption can be achieved through a SSL connection.

Columns can be encrypted / decrypted using functions in the pgcrypto library. Network encryption can be achieved through a SSL connection.

Column data can be encrypted / decrypted using the encryption and decryption methods provided by DB2. If you choose the DATA_ENCRYPT authentication method at the instance level, you can encrypt the network communication between the client and the server.

Audit

Grep can be performed on querylog.

You can use PL/pgSQL triggers on the table for auditing.

The db2audit utility provided by DB2 provides detailed auditing without the need to implement an audit based on triggers or logs.

Query interpretation

Use the EXPLAIN command to view the interpretation plan for the query.

Use the EXPLAIN command to view the interpretation plan for the query.

DB2 provides GUI and command-line tools that can be used to view the interpretation plan of a query. It can also capture queries from the SQL cache and generate interpretation plans. You can use the tool to view the interpretation plan for SQL in all stored procedures.

Backup, recovery, and logging

InnoDB uses write-ahead logging. Full online and offline backups as well as crash and transaction recovery are supported.

Maintain pre-write logs in a subdirectory of the data directory. Support for online and offline full backups as well as crash, point-in-time, and transaction recovery.

Use pre-write logging. Full, incremental, delta, and tablespace-level online / offline backup and recovery are supported. Support for crash, point-in-time, and transaction recovery.

JDBC driver

You can download the JDBC driver from Resources.

You can download the JDBC driver from Resources.

Type-2 and Type-4 (Universal) drivers are supported. The JDBC driver is part of the DB2 product.

Table type

Depends on the storage engine. For example, the NDB storage engine supports partitioned tables and the memory engine supports memory tables.

Temporary tables, regular tables, and partitioned tables of scope and list types are supported. Hash partition tables are not supported.

Supports user tables, temporary tables, regular tables, and partitioned tables of range, hash, and multidimensional cluster types.

Index type

Depends on the storage engine. MyISAM:BTREE,InnoDB:BTREE .

B-tree, hash, R-tree, and Gist indexes are supported.

B-tree and bitmap indexes are supported.

Constraint

Primary key, foreign key, unique and non-null constraints are supported. Check constraints are resolved, but not enforced.

Primary key, foreign key, unique, non-null, and check constraints are supported.

Primary key, foreign key, unique, non-null, and check constraints are supported.

Stored procedures and user-defined functions

CREATE PROCEDURE and CREATE FUNCTION statements are supported. Stored procedures can be written in SQL and C++. User-defined functions can be written in SQL, C, and C++.

Although the term stored procedure is used, only CREATE FUNCTION statements are supported. User-defined functions can be written in PL/pgSQL (proprietary process language), SQL, and C.

CREATE PROCEDURE and CREATE FUNCTION statements are supported. Stored procedures can be written in SQL (SQL PL), C, Java, COBOL, and REXX. User-defined functions can be written in SQL (SQL PL), C, and Java.

Trigger

Pre-row trigger, post-row trigger and statement trigger are supported, and trigger statements are written in procedural language compound statements.

Supports pre-row trigger, post-row trigger and statement trigger, and the trigger process is written in C.

Supports pre-row, post-row and statement triggers, instead of triggers, and triggers that contain SQL PL compound statements. Stored procedures can be called from triggers.

System profile

My.conf

Postgresql.conf

Database Manager Configuration

Database configuration

My.conf

Postgresql.conf

Database Configuration

Client connection file

My.conf

Pg_hba.conf

System Database Directory

Node Directory

XML support

Limited XML support.

Limited XML support.

Provides rich support for accessing XML data. DB2 Viper (V9) is the first hybrid database to store / retrieve XML in its native form.

Data access and management server

OPTIMIZE TABLE-reclaim unused space and remove fragmentation of data files

Myisamchk-analyze-updates the statistics used by the query optimizer (MyISAM storage engine)

Mysql-Command Line tool

MySQL Administrator-client GUI tool

Vacuum-Recycling unused space

Analyze-updates the statistics used by the query optimizer

Psql-Command Line tool

PgAdmin-client GUI tool

Reorg-used to reorganize data and remove data fragmentation

Runstat-collect statistics used by the optimizer

CLP-Command Line tool

Control Center-client GUI tool

Concurrency control

Table-level and row-level locks are supported. The InnoDB storage engine supports READ_COMMITTED, READ_UNCOMMITTED, REPEATABLE_READ, and SERIALIZABLE. Use the SET TRANSACTION ISOLATION LEVEL statement to set the isolation level at the transaction level.

Table-level and row-level locks are supported. The supported ANSI isolation levels are Read Committed (the default-- you can see a snapshot of the database when the query starts) and Serialization (similar to Repeatable Read-- you can only see the results committed before the transaction starts). Use the SET TRANSACTION statement to set the isolation level at the transaction level. Use SET SESSION to set up at the session level.

Table-level and row-level locks and four isolation levels are supported: RR (repeatable read), RS (read reliability), CS (default-cursor reliability), and UR (uncommitted read). Use SET ISOLATION to set the isolation level at the session level, WITH clause at the SQL statement level, or database configuration parameters at the database level.

So far, we have seen some differences in architecture and features among MySQL, PostgreSQL, and DB2. Now take a look at the differences in data types among these database servers.

Go back to the top of the page

Comparison of data types among MySQL, PostgreSQL and DB2

The SQL ANSI standard specifies the rules for the data types used in relational database systems. However, not every database platform supports every data type defined by the Standards Committee. Moreover, vendor implementations of specific data types may differ from the provisions of the standard, even among all database vendors. Therefore, although many MySQL, PostgreSQL, and DB2 data types are similar in name and / or meaning, there are many differences that need to be noted.

Table 2 lists the most commonly used DB2 data types. We provide the closest match between the MySQL and PostgreSQL data types and DB2 in the following sections.

Although DB2 has some restrictions on SQL (such as length restrictions on constraint names, data type restrictions, and so on), new versions are systematically eliminating these restrictions.

Table 2. DB2 data type

Data type

Description

BIGINT

Stores signed or unsigned integers, using 8 bytes of storage space.

BLOB

BLOB (n)

Stores binary data of variable length up to 2 GB. Lengths greater than 1 GB are not logged.

CHAR (n)

CHARACTER (n)

Stores fixed-length character data with a maximum length of 254 bytes. Use'n' bytes of storage space.

CHAR (n) FOR BIT DATA

Stores a fixed-length binary value.

CLOB

CLOB (n)

Stores character data of variable length up to 2 GB. Lengths greater than 1 GB are not logged.

DATE

Stores calendar dates, excluding the time of the day. Use 4 bytes of storage space.

DEC (pencils)

DECIMAL (pencils)

NUM (pencils)

NUMERIC (pencils)

The values are stored with precision (p) 1 to 31 and scale (s) 0 to 31. Use (pram 2) + 1 byte of storage space.

DOUBLE

DOUBLE PRECISION

FLOAT

Stores floating-point numbers, using 8 bytes of storage space.

FLOAT (p)

The precision (p) 1 to 53 is used to store values. If p = 25, it is equivalent to DOUBLE PRECISION.

GRAPHIC (n)

For National Language Support (NLS) and fixed-length strings (usually DBCS) with a maximum length of 127bytes. 2 bytes of storage space is used for double-byte character sets, and n bytes of storage space is used for single-byte character sets.

INT

INTEGER

Stores signed or unsigned integers, using 4 bytes of storage space.

REAL

Stores floating-point numbers, using 4 bytes of storage space.

SMALLINT

Stores signed and unsigned integers, using 2 bytes of storage space.

TIME

Time in the storage day, using 3 bytes of storage space.

TIMESTAMP

Stores the date (year, month, day) and time (hours, minutes, seconds) with a maximum precision of 6 milliseconds. Use 10 bytes of storage space.

VARCHAR (n)

CHAR VARYING (n)

CHARACTER VARYING (n)

Stores character data of variable length up to 32672 bytes. Use nasty 2 bytes of storage space.

VARCHAR (n) FOR BIT DATA

Stores binary data of variable length. Use n bytes of storage space.

VARGRAPHIC (n)

Stores double-byte character data of variable length up to 16336 characters. Use (nasty 2) + 2 bytes of storage space.

MySQL and DB2

Understand the data type problem between MySQL and DB2

In terms of performance, migrate BLOB and CLOB with less than 32K to VARCHAR (n) WITH BIT DATA or VARCHAR (n). The migration tool handles this transformation by studying the actual data in the table.

The migration tool handles UNSIGNED data types.

Migrate the Boolean data type to SMALLINT or CHAR (1).

If the decimal precision is greater than 31, the migration tool converts the column to a double-precision data type.

Automatically incremented columns are migrated to numeric data types and use the IDENTITY clause.

The definitions and differences of MySQL and DB2 data types are described in the following table. Table 3 describes the most commonly used MySQL data types. Table 4 maps the MySQL data type to the nearest DB2 data type.

MySQL can use the SERIAL alias as the data type, which is equivalent to BIGINT UNSIGNED NOT NULL AUTO_INCREMENT UNIQUE.

BOOL or BOOLEAN is synonymous with TINYINT (1). In MySQL, the maximum number of digits for DECIMAL is 65 and the maximum supported decimal place is 30. If UNSIGNED is specified for DECIMAL, negative numbers are not allowed.

The timestamp column does not support milliseconds.

Table 3. MySQL data type

Data type

Description

BIT

A fixed-length bit string.

BOOLEAN

Store logical Boolean values (true/false/unknown), which can be TRUE, true, and 1 false, false, and 0.

TINYBLOB

Used to store raw binary data for binary objects, such as graphics, up to 255 bytes.

BLOB

Used to store raw binary data for binary objects, such as graphics, up to 65535 bytes.

MEDIUMBLOB

Used to store raw binary data for binary objects, such as graphics, up to 16777215 bytes.

LONGBLOB

Used to store raw binary data for binary objects (such as graphics), the maximum 4GB.

CHAR (n)

CHARACTER (n)

Contains a fixed-length string filled with spaces to the length n.

DATE

Use 3 bytes of storage space to store calendar dates (year, month, day).

DATETIME

Use 8 bytes of storage space to store calendar dates and time within days.

YEAR

Use 1 byte of storage space to store years in a two-or four-bit format.

DECIMAL (pencils)

NUMERIC (pencils)

Stores accurate values with a maximum precision (p) of 65 and a scale (s) of 30 or more.

FLOAT

Stores floating-point numbers, and the limit is determined by hardware. Single-precision floating-point numbers are accurate to about 7 decimal places. The UNSIGNED property does not allow negative numbers.

DOUBLE

REAL

Stores double-precision floating-point numbers, and the limit is determined by the hardware. Double-precision floating-point numbers are accurate to about 15 decimal places. The UNSIGNED property does not allow negative numbers.

TINYINT

Stores signed or unsigned 1-byte integers.

SMALLINT

Stores signed or unsigned 2-byte integers.

MEDIUMINT

Stores signed or unsigned 3-byte integers.

INTEGER

Stores signed or unsigned 4-byte integers.

BIGINT

Stores signed or unsigned 8-byte integers.

TINYTEXT

Used to store string data of up to 255 bytes.

TEXT

Used to store string data of up to 65535 bytes.

MEDIUMTEXT

Used to store string data of up to 16777215 bytes.

LONGTEXT

Used to store string data for the most 4GB.

TIME

Use 3 bytes of storage space to store time in the day.

TIMESTAMP

Use 4 bytes of storage space to store dates and times. If no valid value is provided, the TIMESTAMP column is automatically set to the date and time of the most recent operation.

VARCHAR (n)

CHARACTER VARYING (n)

CHARACTER VARYING

Stores a string of variable length, the maximum length specified by n. The trailing space is not stored.

ENUM

A string object whose value can only be one of the values selected from the values list 'value1',' value2',... NULL.

SET

A string object that can have zero or more values that must be value2', from the values list 'value1','. Select from.

BINARY

Similar to the CHAR type, but stores binary byte strings instead of strings.

VARBINARY

Similar to the VARCHAR type, but stores binary byte strings instead of strings.

Table 4. Mapping of MySQL data types to DB2

MYSQL

DB2

Description

BIT

CHAR (n) FOR BIT DATA

See Resources for details on the UDF used to simplify the migration.

BOOLEAN

SMALLINT or CHAR (1)

Use check constraints to enforce rules.

TINYBLOB

VARCHAR (255) FOR BIT DATA

You can use BLOB (255) or VARCHAR (255) FOR BIT DATA. In this case, it is more efficient to use VARCHAR.

BLOB

BLOB (64K)

If the length is less than 32K, consider using VARCHAR (n) FOR BIT DATA.

MEDIUMBLOB

BLOB (16m)

You can use NOT LOGGED to improve performance.

LONGBLOB

BLOB (2G)

The maximum supported BLOB length is 2GB.

CHAR (n)

CHARACTER (n)

CHAR (n)

CHARACTER (n)

In DB2, the maximum value of'n'is 254.

DATE

DATE

-

DATETIME

TIMESTAMP

The date can be converted using the special register CURRENT TIMEZONE.

YEAR

SMALLINT

You can use check constraints to enforce YEAR rules.

DECIMAL (pencils)

NUMERIC (pencils)

DECIMAL (pencils)

NUMERIC (pencils)

If p is greater than 31, use DOUBLE.

FLOAT

REAL

_

DOUBLE

REAL

DOUBLE

_

SMALLINT

SMALLINT

The limit value using check constraints is less than 256.

SMALLINT

SMALLINT

_

MEDIUMINT

INTEGER

If necessary, use check constraints to limit the maximum length.

INTEGER

INTEGER

INT

_

BIGINT

BIGINT

_

TINYTEXT

VARCHAR (255)

For data less than 32K, using VARCHAR is more efficient.

TEXT

CLOB (64K)

DB2 allows you to specify a length parameter for CLOB or BLOB. Specify the desired length instead of using TINY, MEDIUM, or LONG CLOB.

MEDIUMTEXT

CLOB (16m)

_

LONGTEXT

CLOB (2G)

The maximum length is 2GB. If you use LOGGED, the maximum length of BLOB or CLOB is 1GB. Using the NOT LOGGED option can improve performance.

TIME

TIME

_

TIMESTAMP

TIMESTAMP

_

VARCHAR (n)

CHARACTER VARYING (n)

VARCHAR (n)

CHARACTER VARYING (n)

If the length is less than 32K, use VARCHAR.

ENUM

VARCHAR (n)

Use check constraints to enforce rules.

SET

VARCHAR (n)

Use check constraints to enforce rules.

BINARY

CHAR (n) FOR BIT DATA

If n is less than 254, use CHAR (n) FOR BIT DATA; otherwise use VARCHAR (n) FOR BIT DATA.

VARBINARY

VARCHAR (n) FOR BIT DATA

If'n'is less than 32K, use VARCHAR; otherwise use BLOB.

PostgreSQL and DB2

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.