docs.roxen.comView this page in a printer friendly mode
DocsRoxenWebServer 3.3TutorialsDatabase Tutorial
Copyright  2004, Roxen Internet Software
Suggestions, comments & compliments

Building a Sample Database
The query() function
The big_query() function
SQL Syntax
Features Missing from MySQL
Insertion Syntax
The tablify Container
The Business Graphics Module
The emit and sqlquery Tags
Database Creation
Creating Tables

Creating Tables

Tables are created via a mostly standard SQL syntax. When a table is declared, the names and types of its columns are specified, possibly along with constraints, default values and other options.

Most databases, however, allow changing a table structure at any time. Be warned that doing so without breaking any constraint might be not trivial. We won't go into details on how to modify a table structure here. You can check your server's SQL reference manual, looking for the keywords "ALTER TABLE".

Also, we won't go into details on referential integrity constraints. If you need them, you also need a skilled database administrator, and explaining them here would be out of scope.

Again, the SQL standard is not well-specified here. While the basic syntax to create a table is standardized, column types are not (except a few). Also, some servers allow defining custom types, further complicating the matter. Finally, the syntax to define constraints is heavily dialectized, save for the most basic functions. Check your server's documentation for further informations.

We'll use the MySQL syntax as reference.

The basic syntax is:

CREATE TABLE name (declaration[, declaration ...])

The declarations can be columns, keys or indices (see the indices chapter) in various flavors. Let's take a look at a column declaration syntax first: it is

column_name column_type [NOT NULL] [DEFAULT value] [AUTO_INCREMENT] [PRIMARY KEY]

The column name can be pretty much anything, as long as it doesn't clash with any reserved word. For simplicity's sake, using short, descriptive names is advised. Dots, spaces and other non-alphabetical characters are forbidden.

If the NOT NULL clause is specified, it poses a constraint on the column, namely that it must be specified (or, in other terms, it can't be NULL). An attempt to insert a row without specifying this value will result in an SQL error and a (Pike or RXML) exception.

If the DEFAULT clause is specified, inserting a row without specifying this column will result in inserting the default value instead. If it's not specified, NULL will be inserted instead (possibly clashing with the NOT NULL condition).

AUTO_INCREMENT is only meaningful for numeric types, and useful only for integer types. Its behavior is like a specialized default value: if NULL is specified as data for the column, then the actual inserted value will be the maximum present value + 1. This is useful for creating unique IDs for the rows in the table.

We'll return on the PRIMARY KEY argument later.

SQL Data Types

All servers should support at least the INTEGER, REAL, CHAR and VARCHAR types. Unluckily, that's about as far as it goes, and there is even no wide-accepted agreement on the semantics of CHAR and VARCHAR.


is what it seems, an (usually 32-bits) integer. It is signed, unless the keyword UNSIGNED (e.g. INTEGER UNSIGNED) is used.


is a fixed-length character string. Some servers space-pad it at the end (and use the VARCHAR type for unpadded strings), others don't. MySQL doesn't pad it.


is a variable-length string. Usually it differs from CHAR in terms of how it is stored on disk: while CHAR values allocate the storage space for the entire field length (and if it's shorter leave it unused), VARCHAR values are usually stored as a (length, value) pair and are packed. This means that they use less space on disk, but are somewhat slower to access. More importantly, usually VARCHAR values can't be used in indices or keys.

MySQL Data Types

Of course servers provide many more data types. Here are some details on MySQL's types:


are respectively 8-, 16-, 24-, 32-, 64-bit wide integers (signed, 2's complement unless the UNSIGNED clause is specified). Notice that while performing internal arithmetic all values are transformed into 64-bit signed integers, so even for BIGINT UNSIGNED (which is theoretically 64-bit wide, no more than 63 bits values should be used.


are what you can expect them to be (single- and double-precision floating-point numbers).


(length,decimal) is an unpacked floating-point number. It is stored as a string, one char per digit. If DECIMAL is 0, then the numbers are considered integer, and can't have a decimal part. LENGTH is the size, and must be in the 0-255 range.


are date-related types. The legal range for them is from '1000-01-01 00:00:00' to '9999-12-31 23:59:59'. MySQL uses the "yyyy-mm-dd hh:mm:ss" syntax to display dates, but also understands others. It is however recommended to stick to the default.


is a somewhat magic column-type. It stores a date and a time as a 32-bit UNIX datetime value, thus the legal range is from '1970-01-01 00:00:00' to sometime in 2037. It is magic in that when you perform an INSERT or UPDATE operation on a row and don't specify the value for a TIMESTAMP column, MySQL will fill it for you with the date-time of the operation. Useful for time-stamping operations (hence the name).

CHAR (length) [BINARY]

is a fixed-length string as described above. Padding spaces are not added by MySQL. Comparisons are case-insensitive unless the BINARY keyword is specified. length must be in the 1-255 range. Values longer than the specified length are truncated.


is a variable-length string. Same arguments as the CHAR type apply.


are amorphous storage spaces, long at most (2^8-1), (2^16-1), (2^24-1) or (2^32-1) bytes.


are the same as BLOBS, save that comparisons between values are case-insensitive.