Изучаем sql


Обратная сторона индексации



Pdf көрінісі
бет221/261
Дата28.07.2022
өлшемі1,6 Mb.
#147825
1   ...   217   218   219   220   221   222   223   224   ...   261
Байланысты:
Изучаем SQL ( PDFDrive )

Обратная сторона индексации
Если индексы – это так замечательно, почему бы не индексировать все
подряд? Чтобы понять, почему большее количество индексов не всегда
хорошо, надо помнить, что каждый индекс – это таблица (особого ти
па, но все равно таблица). Поэтому при каждом добавлении или удале
нии строки из таблицы все ее индексы должны быть модифицирова
ны. При обновлении строки все задействованные индексы столбца или
столбцов тоже должны изменяться. Следовательно, чем больше индек
сов, тем больше работы приходится выполнять серверу для обновле
ния всех объектов схемы. А это очень замедляет процесс.
Индексам требуется некоторое количество памяти, а также некоторое
внимание администраторов, поэтому наилучшая стратегия – добавлять


Ограничения
251
индекс только при возникновении вполне определенной необходимо
сти. Если индекс нужен только для конкретной цели, например для
выполнения программы по ежемесячному обслуживанию, всегда мож
но добавить индекс, выполнить программу и удалить индекс до того
момента, пока он не понадобится вновь. Для хранилищ данных, где
индексы очень нужны в рабочие часы (поскольку пользователи состав
ляют отчеты и выполняют случайные запросы), но становятся пробле
мой при загрузке данных в хранилище в ночное время, общепринятой
практикой является уничтожение индексов перед загрузкой данных
и их повторное создание перед открытием хранилищ для работы.
Ограничения
Ограничение – это просто некоторое ограничивающее условие, нала
гаемое на один или более столбцов таблицы. Есть несколько разных
типов ограничений, включая:
Ограничения первичного ключа (Primarykey constraints)
Идентифицируют столбец или столбцы, гарантирующие уникаль
ность в рамках таблицы.
Ограничения внешнего ключа (Foreignkey constraints)
На один или более столбцов накладывается такое ограничение: они
могут содержать только значения, содержащиеся в столбцах первич
ного ключа другой таблицы. Также могут ограничиваться допусти
мые значения других таблиц, если установлены правила 
update
cas
cade
(каскадное обновление) или 
delete
cascade
(каскадное удаление).
Ограничения уникальности (Unique constraints)
На один или более столбцов накладывается ограничение: они могут
содержать только уникальные в рамках таблицы значения.
Проверочные ограничения целостности (Check constraints)
Ограничивают допустимые значения столбца.
Без ограничений под сомнением может оказаться непротиворечивость
базы данных. Например, если сервер допускает изменение ID клиента
в таблице 
customer
без изменения этого же ID клиента в таблице 
ac
count
, все может закончиться тем, что счета больше не будут указывать
на соответствующие записи клиентов (это явление известно как «оси
ротевшие» строки (orphaned rows)). Но если заданы ограничения пер
вичного и внешнего ключей, сервер или сформирует ошибку в случае
попытки изменения или удаления данных, на которые ссылаются дру
гие таблицы, или распространит изменения на другие таблицы (более
подробно об этом чуть позже).
Если при работе с сервером MySQL требуются ограничения внеш
него ключа, в таблицах должен использоваться механизм хра
нения InnoDB.




Достарыңызбен бөлісу:
1   ...   217   218   219   220   221   222   223   224   ...   261




©engime.org 2024
әкімшілігінің қараңыз

    Басты бет