Любые мыслимые данные можно хранить с помощью числовых или символьных типов. В 
принципе, даже числа можно хранить в символьном виде. Однако то, что это можно 
сделать, не означает, что это нужно делать. Рассмотрим, к примеру, как хранить 
в базе данных денежные суммы. Можно делать это, используя INT или REAL. Хотя 
интуитивно REAL может показаться более подходящим - в конце концов, в денежных 
суммах нужны десятичные знаки, - на самом деле более правильно использовать INT.
 В полях, содержащих значения с плавающей запятой, таких как REAL, часто 
невозможно найти число с точным десятичным значением. Например, если вы вводите 
число 0.43, которое должно представлять сумму $0.43, MySQL и mSQL могут 
записать его как 0.42999998. Это небольшое отличие может вызвать проблемы при 
совершении большого числа математических операций. Сохраняя число как INT и 
устанавливая десятичную точку в нужное место, можно быть уверенным, что его 
значение представляет именно то, что вам требуется.
К чему такие хлопоты? Не лучше ли было бы, если бы MySQL и mSQL обеспечивали 
некий тип данных, специально предназначенный для денежных сумм? MySQL и в 
меньшей степени mSQL предоставляют специальные типы данных для таких случаев. 
Одним из них является тип MONEY, другим- DATE. Полное описание всех типов 
данных можно найти в главе 17 «Программы и утилиты для MySQL и mSQL».
Индексы
Хотя MySQL и mSQL обеспечивают более высокую производительность, чем любые 
большие серверы баз данных, некоторые задачи все же требуют осторожности при 
проектировании базы данных. Например, если таблица содержит миллионы строк, 
поиск нужной строки в ней наверняка потребует длительного времени. Как 
указывалось в главе 2, в большинстве баз данных поиск облегчается благодаря 
средству, называемому индексом.
Индексы способствуют хранению данных в базе таким образом, который позволяет 
осуществлять быстрый поиск. К несчастью, ради скорости поиска приходится 
жертвовать дисковым пространством и скоростью изменения данных. Наиболее 
эффективно создавать индексы для тех колонок, в которых вы чаще всего 
собираетесь осуществлять поиск. MySQL и mSQL поддерживают одинаковый синтаксис 
для создания индексов:
CREATE INDEX index_name ON tablename (column1,
column2,
columnN)
MySQL позволяет также создавать индекс одновременно с созданием таблицы, 
используя следующий синтаксис:
CREATE TABLE materials (id INT NOT NULL,
name CHAR(50) NOT NULL,
resistance INT, 
melting_pt REAL,
INDEX indexl (id, name), 
UNIQUE INDEX index2 (name))
В этом примере для таблицы создается два индекса. Первый индекс indexl состоит 
из полей id и name. Второй индекс включает в себя только поле name и указывает, 
что значения поля name должны быть уникальными. Если вы попытаетесь вставить в 
поле name значение, которое уже есть в этом поле в какой-либо строке, операция 
не будет осуществлена. Все поля, указанные в уникальном индексе, должны быть 
объявлены как NOT NULL .
Хотя мы создали отдельный индекс для поля name, отдельно для поля id мы не 
создавали индекса. Если такой индекс нам понадобится, создавать его не нужно - 
он уже есть. Когда индекс содержит более одной колонки (например, name, rank, 
nserial_number), MySQL читает колонки в порядке слева направо. Благодаря 
используемой MySQL структуре индекса всякое подмножество колонок с левого края 
автоматически становится индексом внутри «главного» индекса. Например, когда вы 
создаете индекс name, rank, serial_number, создаются также «свободные» индексы 
name и name вместе с rank. Однако индексы rank или name и seri-al_number не 
создаются, если не потребовать этого явно.
MySQL поддерживает также семантику ANSI SQL для особого индекса, называемого 
первичным ключом. В MySQL первичный ключ - это уникальный индекс с именем 
PRIMARY. Назначив при создании таблицы колонку первичным ключом, вы делаете ее 
уникальным индексом, который будет поддерживать объединения таблиц. В следующем 
примере создается таблица cities с первичным ключом id.
CREATE TABLE cities (id INT NOT NULL PRIMARY KEY,
name VARCHAR(100),
pop MEDIUMINT,
founded DATE)
Прежде чем создавать таблицу, нужно решить, какие поля будут ключами (и будут 
ли вообще ключи). Как уже говорилось, любые поля, которые будут участвовать в 
объединении таблиц, являются хорошими кандидатами на роль первичного ключа. 
Подробно обсуждение того, как проектировать таблицы с хорошими первичными 
ключами, можно найти в главе 2.
Последовательности и автоинкрементирование
Лучше всего, когда первичный ключ не имеет в таблице никакого иного значения, 
кроме значения первичного ключа. Для достижения этого лучшим способом является 
создание числового первичного ключа, значение которого увеличивается при 
добавлении в таблицу новой строки. Если вернуться к примеру с таблицей cities, 
то первый введенный вами город должен иметь id, равный 1, второй - 2, третий - 
3, и т. д. Чтобы успешно управлять такой последовательностью первичных ключей, 
нужно иметь какое-то средство, гарантирующее, что в данный конкретный момент 
только один клиент может прочесть число и увеличить его на единицу. В базе