Накопились вопросики и решил спросить здешних гуру
1) Как можно удалить целиком таблицу, не удаляя каждую ее строки? Есть ли какой нить механизм?
2) Что есть CUBE?
3) alter меняют структуру уже существующих обектов. Где может понадобиться такой подход? Пока мне кажеться, что это всего лишь заплатка в проектировании.
4) Primary key. Что физически несет под собой ключевое слово? Будет ли иметь существенную разницу, если я буду использовать просто
unique? Создаеться ли автоматом для этой колонки индекс?
5) (соот к 4 п.) Для работы с индексированной таблицей мне достаточно создать индекс для нужной колонки и уже прозрачно работать с запросами (не заботясь о индексах, как будто их не существует). Почему же я не могу (вернее даже СУБД) автоматом на создавать для каждого поля по индексу? Все будет работать очень быстро и все будут счастливы. НО. Здравый смысл мне подсказывает, что бесплатный сыр бывает только в мышелвке. Где же подвох? Для каких размерностей таблиц лучше вводить индексы, а для каких нет?
6) при создании таблицы, если поле указать как DEFAULT, гарантирует ли он NOT NULL? Или я же смогу проделать такой запрос "insert into ObsoleteTable VALUES(NULL, bla-bla-bla)"?
7) можно ли исполльзовать операцию INSERT более одного раза? И если нет, то почему?
8) Я этот вопрос уже задавал. Но не получил ответа. Поэтому, пользуясь случаем хочу: во-первых, передать привет маме, а во-вторых спросить еще раз. Где же разница между functions & procedures ?
Здравствуйте, Mika Soukhov, Вы писали:
MS>1) Как можно удалить целиком таблицу, не удаляя каждую ее строки? Есть ли какой нить механизм?
drop table
MS>3) alter меняют структуру уже существующих обектов. Где может понадобиться такой подход? Пока мне кажеться, что это всего лишь заплатка в проектировании.
Это часто бывает необходимо при развитии программы (базы), когда уже в существующую таблицу мы хотим добавить новые колонки. И при этом не хотим прерывать работу базы.
MS>4) Primary key. Что физически несет под собой ключевое слово? Будет ли иметь существенную разницу, если я буду использовать просто MS>unique? Создаеться ли автоматом для этой колонки индекс?
Именно по Primary Key идентифицируются отдельные записи. Индекс создается автоматом.
Primary key может быть построен по нескольким записям в отличии от unique.
MS>5) (соот к 4 п.) Для работы с индексированной таблицей мне достаточно создать индекс для нужной колонки и уже прозрачно работать с запросами (не заботясь о индексах, как будто их не существует). Почему же я не могу (вернее даже СУБД) автоматом на создавать для каждого поля по индексу? Все будет работать очень быстро и все будут счастливы. НО. Здравый смысл мне подсказывает, что бесплатный сыр бывает только в мышелвке. Где же подвох? Для каких размерностей таблиц лучше вводить индексы, а для каких нет?
Подвох в том, что при вставке новых или изменении существующих записей, необходимо перестраивать индексы, что приводит к довольно ощутимым тормозам.
При кол-ве записей больше 1000 индексы очень желательны.
MS>6) при создании таблицы, если поле указать как DEFAULT, гарантирует ли он NOT NULL? Или я же смогу проделать такой запрос "insert into ObsoleteTable VALUES(NULL, bla-bla-bla)"?
на первый взгляд (лень лезть в документацию), я не вижу взаимосвязи между default и not null.
MS>7) можно ли исполльзовать операцию INSERT более одного раза? И если нет, то почему?
Все еще MSSQL?
MS>1) Как можно удалить целиком таблицу, не удаляя каждую ее строки? Есть ли какой нить механизм?
В зависимости от того, что тебе надо...
DROP TABLE — удаляет таблицу вообще.
TRUNCATE TABLE — удаляет все записи из таблицы, работает эффективнее чем DELETE FROM без WHERE, так как меньше информации пишется в журнал транзакций.
MS>2) Что есть CUBE?
Вычисляет сумму по столбцу в выборке и выдает ее дополнительной строкой, работает вместе с GROUP. Ту же самую функциональность при желании можно сделать и руками, так что это не более чем syntactic shugar.
MS>3) alter меняют структуру уже существующих обектов. Где может понадобиться такой подход? Пока мне кажеться, что это всего лишь заплатка в проектировании.
Все возможно. Иногда может потребоваться изменить структуру базы на лету или с сохраненгием данных.
MS>4) Primary key. Что физически несет под собой ключевое слово? Будет ли иметь существенную разницу, если я буду использовать просто MS>unique? Создаеться ли автоматом для этой колонки индекс?
Строго говоря физически это слово не несет ничего. Однако в MSSQL'е автоматом, если не указать обратного, создается кластерный индекс.
Можно использовать просто unique, можно использовать даже не unique, сервер тебе плохого слова не скажет, другое дело, что подобное решение будет несколько странноватым.
MS>5) (соот к 4 п.) Для работы с индексированной таблицей мне достаточно создать индекс для нужной колонки и уже прозрачно работать с запросами (не заботясь о индексах, как будто их не существует). Почему же я не могу (вернее даже СУБД) автоматом на создавать для каждого поля по индексу? Все будет работать очень быстро и все будут счастливы.
Работать быстро будет не все, а только выборка. А вот вставка и изменения в этом случае будут наоборот, конкретно подтормаживать.
Чем больше индексов, тем грустнее. Ведь на каждую вставку нужно добавить соответствующие записи во все индексы, а при изменении — изменить.
Ну и размер соответственно, индексы тоже место занимают.
MS>Для каких размерностей таблиц лучше вводить индексы, а для каких нет?
От ситуации зависит. Вообще индексы очень тонкая штука почитай например Index Tuning Wizard for Microsoft SQL Server 2000 в MSDN.
MS>6) при создании таблицы, если поле указать как DEFAULT, гарантирует ли он NOT NULL? Или я же смогу проделать такой запрос "insert into ObsoleteTable VALUES(NULL, bla-bla-bla)"?
Нет, NOT NULL не гарантируется — это совершенно не взаимосвязанные вещи.
MS>7) можно ли исполльзовать операцию INSERT более одного раза? И если нет, то почему?
Тоесть?
MS>8)Поэтому, пользуясь случаем хочу: во-первых, передать привет маме,
Это не сюда, это в телевизор
MS> а во-вторых спросить еще раз. Где же разница между functions & procedures ?
Functions: можно использовать непосредственно в запросе.
e. g. SELECT * FROM functions('parametr1',...) или SELECT functions('parametr1',...) FROM... Возможны варианты.
Внутри функций нельзя использовать nondeterministics функции. Тоесть такие функции, которые могут вернуть разный результат при одинаковых входных параметрах.
По большему счету функция — это view с параметрами.
Procedures: Ну тут думаю сам разберешся. Набор T-SQL команд.
Здравствуйте, Mika Soukhov, Вы писали:
MS>1) Как можно удалить целиком таблицу, не удаляя каждую ее строки? Есть ли какой нить механизм?
Может имеешь в виду truncate table tablename? Это чтоб быстро и в обход триггеров и лога транзакций.
MS>3) alter меняют структуру уже существующих обектов.
Ну, я б так не утверждал.
alter table позволяет, например, отключать/включать триггеры и индексы.
без alter database вообще трудно нормально жить.
MS>Для каких размерностей таблиц лучше вводить индексы, а для каких нет?
Вопрос об использовании индексов решается не в зависимости от количества полей или записей в таблицах (слава богу, все современные оптимизаторы в состоянии определить, надо им идти по индексу или table scan быстрее будет, если, например, в таблице 2 записи), а от запросов, которые существуют в системе. Если у меня в таблице уникальный индекс по 3-м полям — один вариант, если надо линковаться с другой таблицей по какому-либо полю — другой вариант.
MS>6) при создании таблицы, если поле указать как DEFAULT, гарантирует ли он NOT NULL?
Однозначно нет. MS>Или я же смогу проделать такой запрос "insert into ObsoleteTable VALUES(NULL, bla-bla-bla)"?
Однозначно да.
MS>7) можно ли исполльзовать операцию INSERT более одного раза? И если нет, то почему?
Условно:
create table aa (
numeric(18,0) identity,
varchar(10) not null
)
insert into a values ('text') — запускай хоть весь рабочий день.
Здравствуйте, Merle, Вы писали:
M>Здравствуйте, Mika Soukhov, Вы писали:
M>Все еще MSSQL?
Ну, да. Не оракл же
MS>>1) Как можно удалить целиком таблицу, не удаляя каждую ее строки? Есть ли какой нить механизм? M>В зависимости от того, что тебе надо... M>DROP TABLE — удаляет таблицу вообще.
Вот насчет этого прочитал что операция не может быть выполнена если в таблице есть записи Так сказать от несанкционированного запроса. Похоже, врут.
MS>>2) Что есть CUBE? M>Вычисляет сумму по столбцу в выборке и выдает ее дополнительной строкой, работает вместе с GROUP. Ту же самую функциональность при желании можно сделать и руками, так что это не более чем syntactic shugar.
Странная функциональность. Неужели я не знаю, сколько я не знаю сколько столбцов мне должно вернуться...
MS>>7) можно ли исполльзовать операцию INSERT более одного раза? И если нет, то почему? M>Тоесть?
Можно ли в одном запросе (через UNION или вложенный) сделать больше одной команды INSERT. Я, опять же, не помню где это читал (возможно это была статейка про MySQL), но там говорилось что INSERT можно делать только один раз за запрос. Так ли?
Здравствуйте, DarkGray, Вы писали:
MS>>4) Primary key. Что физически несет под собой ключевое слово? Будет ли иметь существенную разницу, если я буду использовать просто MS>>unique? Создаеться ли автоматом для этой колонки индекс?
DG>Именно по Primary Key идентифицируются отдельные записи. Индекс создается автоматом. DG>Primary key может быть построен по нескольким записям в отличии от unique.
Ай-яй-яй! Зачем обманываешь людей? Ограничение UNIQUE тоже может быть для нескольких столбцов.
С помощью UNIQUE явным образом указываются потенциальные ключи, а с помощью PRIMARY KEY — первичный ключ. Для чего нужно выделять первичный ключ из мнжества потенциальных — это надо читать теоретические изыскания крутых мужиков. Насколько я помню для UNIQUE тоже создаются индексы.
Здравствуйте, Mika Soukhov, Вы писали:
MS>Вот насчет этого прочитал что операция не может быть выполнена если в таблице есть записи Так сказать от несанкционированного запроса. Похоже, врут.
Ну если в эту таблицу какая-то транзакция вставила запись и еще не отработала, то Drop из другой транзакции не пройдет, а будет ждать фиксации/отката первой. Может быть это имелось ввиду.
M>>Вычисляет сумму по столбцу в выборке и выдает ее дополнительной строкой, работает вместе с GROUP. Ту же самую функциональность при желании можно сделать и руками, так что это не более чем syntactic shugar. MS>Странная функциональность. Неужели я не знаю, сколько я не знаю сколько столбцов мне должно вернуться...
Нет, CUBE вычисляет не количество столбцов, а сумму данных в каком-то столбце. Вот пример из BOL:
SELECT Item, Color, SUM(Quantity) AS QtySum
FROM Inventory
GROUP BY Item, Color WITH CUBE
Here is the result set:
Item Color QtySum
-------------------- -------------------- --------------------------
Chair Blue 101.00
Chair Red 210.00
Chair (null) 311.00
Вот последняя строчка и есть результат CUBE. Он посчитал сумму всех данных в столбце QtySum, 101+210=311
MS>Можно ли в одном запросе (через UNION или вложенный) сделать больше одной команды INSERT. Я, опять же, не помню где это читал (возможно это была статейка про MySQL), но там говорилось что INSERT можно делать только один раз за запрос. Так ли?
UNION применяется только к SELECT'у, а вот делать INSERT... INSERT... в одном запросе можешь сколько угодно.
Здравствуйте, Merle, Вы писали:
M>Здравствуйте, Mika Soukhov, Вы писали:
MS>>Вот насчет этого прочитал что операция не может быть выполнена если в таблице есть записи Так сказать от несанкционированного запроса. Похоже, врут. M>Ну если в эту таблицу какая-то транзакция вставила запись и еще не отработала, то Drop из другой транзакции не пройдет, а будет ждать фиксации/отката первой. Может быть это имелось ввиду.
Вы должны быть собственником( т.е. быть создателем ) таблицы чтобы
иметь возможность удалить ее. Поэтому не волнуйтесь о случайном разру-
шении ваших данных, SQL сначала потребует чтобы вы очистили таблицу
прежде, чем удалит ее из базы данных. Таблица с находящимися в ней
строками, не может быть удалена. Обратитесь к Главе 15 за подробностя-
ми относительно того как удалять строки из таблицы. Синтаксис для уда-
ления вашей таблицы, если конечно она является пустой, следующая:
DROP TABLE < table name >;
M>>>Вычисляет сумму по столбцу в выборке и выдает ее дополнительной строкой, работает вместе с GROUP. Ту же самую функциональность при желании можно сделать и руками, так что это не более чем syntactic shugar. MS>>Странная функциональность. Неужели я не знаю, сколько я не знаю сколько столбцов мне должно вернуться... M>Нет, CUBE вычисляет не количество столбцов, а сумму данных в каком-то столбце. Вот пример из BOL:
M>
M>SELECT Item, Color, SUM(Quantity) AS QtySum
M>FROM Inventory
M>GROUP BY Item, Color WITH CUBE
M>
M>
M>Here is the result set:
M>Item Color QtySum
M>-------------------- -------------------- --------------------------
M>Chair Blue 101.00
M>Chair Red 210.00
M>Chair (null) 311.00
M>
А зачем нужен операция "CREATE CUBE"? В твоем же примере Куб выступает как ключевое слово
M>Вот последняя строчка и есть результат CUBE. Он посчитал сумму всех данных в столбце QtySum, 101+210=311
Кстати раз уж речь зашла о GROUP BY, можешь рассказать по подробнее? Я так и не понял о какой группировке идет речь.
MS> Вы должны быть собственником( т.е. быть создателем ) таблицы чтобы
MS>иметь возможность удалить ее. Поэтому не волнуйтесь о случайном разру-
MS>шении ваших данных, SQL сначала потребует чтобы вы очистили таблицу
MS>прежде, чем удалит ее из базы данных. Таблица с находящимися в ней
MS>строками, не может быть удалена. Обратитесь к Главе 15 за подробностя-
MS>ми относительно того как удалять строки из таблицы. Синтаксис для уда-
MS>ления вашей таблицы, если конечно она является пустой, следующая:
MS> DROP TABLE < table name >;
Хм.. Либо имелся ввиду какой-то другой SQL сервер, либо одно из двух.
Впрочем вот такой незатейливый скрипт должен развеять все сомнения:
CREATE TABLE test (a int)
INSERT INTO test(a) VALUES(10)
GO
DROP TABLE test
Таблица test дропнется и даже не икнет, несмотря на то, что не пустая..
MS>А зачем нужен операция "CREATE CUBE"? В твоем же примере Куб выступает как ключевое слово
Эээ, брат... CREATE CUBE — это совершенно отдельная песТня. Эта конструкция относится не к MSSQL'ю, как таковому, а к его OLAP составляющей.
Вообщем если хочешь получше разобраться, надо почитать что такое OLAP, и что за кубы там имеют место быть.
Посмотри например http://www.olap.ru, там было несколько обзорных статей, как мне помнится.
Только поправки к существующим ответам.
MS>3) alter меняют структуру уже существующих обектов. Где может понадобиться такой подход? Пока мне кажеться, что это всего лишь заплатка в проектировании.
Да, но живой проект без них не может. А иногда старый панцирь (структуру данных) целиком сбрасывает.
MS>4) Primary key. Что физически несет под собой ключевое слово? Будет ли иметь существенную разницу, если я буду использовать просто MS>unique? Создаеться ли автоматом для этой колонки индекс?
Primary отличается от остальных unique тем, что он главный. По нему записи сортируются физически. То есть в полностью оптимизированной таблице последовательный доступ по Primary последовательности теоретически быстрее, чем по другим ключам. Когда нам нужна вся запись, а не только ключ.
MS>5) (соот к 4 п.) Для работы с индексированной таблицей мне достаточно создать индекс для нужной колонки и уже прозрачно работать с запросами (не заботясь о индексах, как будто их не существует). Почему же я не могу (вернее даже СУБД) автоматом на создавать для каждого поля по индексу? Все будет работать очень быстро и все будут счастливы. НО. Здравый смысл мне подсказывает, что бесплатный сыр бывает только в мышелвке. Где же подвох? Для каких размерностей таблиц лучше вводить индексы, а для каких нет?
Опыт показывает: вводи индексы для всего, что индексируется. При вставке тормоза незначительны и на них обычно можно наплевать, но тормоза, которые ты можешь получить при каком-нибудь новом запросе, на который вначале не рассчитывал и индекса не ввел, бывают катастрофическими.
K> Опыт показывает: вводи индексы для всего, что индексируется. При вставке тормоза незначительны и на них обычно можно наплевать, но тормоза, которые ты можешь получить при каком-нибудь новом запросе, на который вначале не рассчитывал и индекса не ввел, бывают катастрофическими.
Все зависит от соотношения между кол-вом объемом получаемых данных и объемом закачиваемых/изменяемых данных.
Если доля вторых достаточно велика, то индексы могут серьезно тормозить систему.
зы
Но я согласен с тем, что у типичных проектов (склад, магазин, форум и т.д.) объем получаемых данных много больше, чем добавляемых/изменяемых данных.
Но есть и нетипичные проекты, например, когда база часто синхронизируется свое состояние с состоянием "живого объекта/системы".
K> Primary отличается от остальных unique тем, что он главный. По нему записи сортируются физически. То есть в полностью оптимизированной таблице последовательный доступ по Primary последовательности теоретически быстрее, чем по другим ключам. Когда нам нужна вся запись, а не только ключ.
IMHO это относится к кластерности PK или иного индекса.
Если ПК некластерный — то по его индексу будут не записи а просто букмарки.
Здравствуйте, kulentsov, Вы писали:
K>Только поправки к существующим ответам.
Не, нельзя так народ путать...
MS>>4) Primary key. Что физически несет под собой ключевое слово? Будет ли иметь существенную разницу, если я буду использовать просто MS>>unique? Создаеться ли автоматом для этой колонки индекс? K> Primary отличается от остальных unique тем, что он главный. По нему записи сортируются физически. То есть в полностью оптимизированной таблице последовательный доступ по Primary последовательности теоретически быстрее, чем по другим ключам. Когда нам нужна вся запись, а не только ключ.
Так, вот здесь я чувствую надо порядок в умах наводить. Итак в дальнейшем у нас на повестке дня MSSQL.
PK — он же Primary Key, он же обрусевший Первичный Ключ — есть понятие сугубо абстрактное и эфемерное, токмо для разработчика предназначенное. Серверу абсолютно монопенисуально является ли столбец PK или нет. В MSSQL'е есть ключевое слово PRIMARY KEY, это специальный констрэйнт, который заставляет столбец, или группу столбцов, быть уникальными и не принимать значание NULL. Если при этом в таблице не существует кластерный индекс, то он создается по этому столбцу/столбцам. Если те же самые действия проделать в ручную, то никакой разницы не будет.
Что такое "кластерный индекс"? Это отдельная история.
В MSSQL'е таблица может быть кластеризована (Clustered) и не кластеризована (Heap).
Конкретная запись в не кластеризованной таблице идентифицируется по ID_таблицы, ID_страницы, ID_записи. Соответственно при построении обычного индекса запись находится именно таким способом, при этом сами записи никоем образом не упорядочены, отсюда и название(Heap).
Если же мы строим по какому-нибудь полю/полям в таблице кластерный индекс, то каждой строке присваивается уникальный ключ и сами строки располагаются в том же порядке, что и записи в кластерном индексе. После этого отпадает необходимость пользоваться изнурительной комбинацией ID'шников для идентификации строки и все индексы начинают ссылаться на кластерный индекс.
Плюс к этому индекс в MSSQL'е это B-Tree, а значит по определению отсортирован, таким образом, таблица у нас получается отсортированной. Но не совсем. Создание кластерного индекса не означает физическое упорядочивание записей в соответствии с задаваемым им порядком. Кластерный индекс физически упорядочивает записи внутри страниц и логически упорядочивает страницы в виде двунаправленного списка при помощи полей NextPageFID, NextPagePID, PrevPageFID, PrevPagePID, которые в его отсутствие обычно нулевые. Именно в порядке этих указателей теперь происходит сканирование таблицы. Для желающих можно набросать простенький эксперемент.
И еще раз хочу напомнить, что объявление PK вовсе не означает создание кластерного индекса.
Так что записи вовсе не обязательно будут отсортированы по PK физически, хотя чисто теоретически такая вероятность есть.
K> Опыт показывает: вводи индексы для всего, что индексируется. При вставке тормоза незначительны и на них обычно можно наплевать, но тормоза, которые ты можешь получить при каком-нибудь новом запросе, на который вначале не рассчитывал и индекса не ввел, бывают катастрофическими.
Мой опыт мне как раз подсказывает обратное. Проектировать базу надо так, чтобы не возникало необходимости в ad-hoc запросах, за исключением тех случаев, когда поддержка таких запросов является требованием заказчика. Потому как обычно непредусмотренные запросы оборачиваются тотальным переделыванием всей архитектуры и простым добавлением индекса здесь не отделаешься.
А вот бездумное пихание индексов куда попало, как правило приводит к конкретным тормозам. Выбор же кластерного индекса — это вообще стратегический вопрос, кластерный индекс по PK в большинстве случаев лучше чем ничего, и поэтому тут сервер проявляет некоторое самоуправство приходя на помощ неопытному разработчику, но это далеко не всегда оптимальное решение.
Здравствуйте, Merle, Вы писали:
K>>Только поправки к существующим ответам. M>Не, нельзя так народ путать...
Я не путаю. Просто я описываю generic ситуацию, а не MSSQL. Ближе к MySQL.
M>Так, вот здесь я чувствую надо порядок в умах наводить. Итак в дальнейшем у нас на повестке дня MSSQL.
... M>Если же мы строим по какому-нибудь полю/полям в таблице кластерный индекс, то каждой строке присваивается уникальный ключ и сами строки располагаются в том же порядке, что и записи в кластерном индексе. После этого отпадает необходимость пользоваться изнурительной комбинацией ID'шников для идентификации строки и все индексы начинают ссылаться на кластерный индекс.
... что и является более общим случаем для баз данных.
M>И еще раз хочу напомнить, что объявление PK вовсе не означает создание кластерного индекса.
... в MS SQL. В тех же MyISAM любой индекс в терминологии M$ получается "кластерный". M>Так что записи вовсе не обязательно будут отсортированы по PK физически, хотя чисто теоретически такая вероятность есть.
K>> Опыт показывает: вводи индексы для всего, что индексируется. При вставке тормоза незначительны и на них обычно можно наплевать, но тормоза, которые ты можешь получить при каком-нибудь новом запросе, на который вначале не рассчитывал и индекса не ввел, бывают катастрофическими. M>Мой опыт мне как раз подсказывает обратное. Проектировать базу надо так, чтобы не возникало необходимости в ad-hoc запросах,
Невозможно! M>за исключением тех случаев, когда поддержка таких запросов является требованием заказчика. Потому как обычно
Именно. Из законов проектирования корпоративных баз: "Скоро заказчик захочет иметь статистику, которая не предусмотрена системой, требует сложных вычислений по всей базе и невозможна при удалении старых данных из основной базы. Но это желание появится не раньше, чем часть старых данных будет перенесена в архив или уничтожена".
M>непредусмотренные запросы оборачиваются тотальным переделыванием всей архитектуры и простым добавлением индекса здесь не отделаешься.
А это уже у кого как. При правильном проектировании живого проекта у модели должны быть, как бы это назвать, "выпуски".
Это когда арматура из бетона торчит.
M>А вот бездумное пихание индексов куда попало, как правило приводит к конкретным тормозам. Выбор же кластерного
... в MS SQL опять же, наверное. Меня это всегда удивляло. Может, потому, что у меня еще не было проектов, где данные апдейтились бы чаще, чем использовались для выборок. M>индекса — это вообще стратегический вопрос, кластерный индекс по PK в большинстве случаев лучше чем ничего, и поэтому тут сервер проявляет некоторое самоуправство приходя на помощ неопытному разработчику, но это далеко не всегда оптимальное решение.
По мне так это очень простой вопрос. Если у нас "ничего", это просто несоответствие парадигме SQL, где каждая запись должна быть уникально идентифицируема. Я бы вообще запретил создавать таблицы без явно заданного ключа.
Здравствуйте, kulentsov, Вы писали:
M>>Не, нельзя так народ путать... K> Я не путаю. Просто я описываю generic ситуацию, а не MSSQL. Ближе к MySQL.
Не, это не generic ситуация, а непонятно что.
В generic, если вспомнить реляционную теорию, PK — уникальный идентификатор, про упорядоченность и все остальное там ни слова.
M>>Так, вот здесь я чувствую надо порядок в умах наводить. Итак в дальнейшем у нас на повестке дня MSSQL. K>... M>>Если же мы строим по какому-нибудь полю/полям в таблице кластерный индекс, то каждой строке присваивается уникальный ключ и сами строки располагаются в том же порядке, что и записи в кластерном индексе. После этого отпадает необходимость пользоваться изнурительной комбинацией ID'шников для идентификации строки и все индексы начинают ссылаться на кластерный индекс. K> ... что и является более общим случаем для баз данных.
Тоесть? Что здесь является более общим случаем?
M>>И еще раз хочу напомнить, что объявление PK вовсе не означает создание кластерного индекса. K> ... в MS SQL. В тех же MyISAM любой индекс в терминологии M$ получается "кластерный".
Такого просто не может быть. Кластерный индекс, в терминологии MS, по определению может быть только один. Нельзя отсортировать одну таблицу одновременно двумя разными способами. Тогда это будут уже две таблицы.
Собственно я в прошлый раз забыл добавить почему именно так получается. В кластерном индексе "листья" не ссылаются на данные, как в обычном индексе, а сами данные являются "листьями", отсюда и сортировка.
M>>Мой опыт мне как раз подсказывает обратное. Проектировать базу надо так, чтобы не возникало необходимости в ad-hoc запросах, K> Невозможно!
Нет ничего невозможного, если с умом подходить, а не раскладывать индексы по углам, на всякий случай..
M>>за исключением тех случаев, когда поддержка таких запросов является требованием заказчика. Потому как обычно K> Именно. Из законов проектирования корпоративных баз: "Скоро заказчик захочет иметь статистику, которая не предусмотрена системой, требует сложных вычислений по всей базе и невозможна при удалении старых данных из основной базы. Но это желание появится не раньше, чем часть старых данных будет перенесена в архив или уничтожена".
Вот именно об этом я и говорю.
Одним индексом "на выпуск" в таких случаях не отделаешься. Индекс — это вообще мелочь, пять минут ленивой работы.
M>>непредусмотренные запросы оборачиваются тотальным переделыванием всей архитектуры и простым добавлением индекса здесь не отделаешься. K> А это уже у кого как. При правильном проектировании живого проекта у модели должны быть, как бы это назвать, "выпуски". K>Это когда арматура из бетона торчит.
Главное не спотыкаться об эту арматуру в самый неподходящий момент. Этот самый "выпуск" заключается уж ни как ни в делании индексов по всему, что можно.
M>>А вот бездумное пихание индексов куда попало, как правило приводит к конкретным тормозам. Выбор же кластерного K> ... в MS SQL опять же, наверное. Меня это всегда удивляло.
Что именно? Что выбор индекса штука не тривиальная?
K>Может, потому, что у меня еще не было проектов, где данные апдейтились бы чаще, чем использовались для выборок.
А чаще и не обязательно. Достаточно пары десятков процентов, чтобы в серьез задуматься о потребности содержать индексы "про запас".
M>>индекса — это вообще стратегический вопрос, кластерный индекс по PK в большинстве случаев лучше чем ничего, и поэтому тут сервер проявляет некоторое самоуправство приходя на помощ неопытному разработчику, но это далеко не всегда оптимальное решение. K> По мне так это очень простой вопрос. Если у нас "ничего", это просто несоответствие парадигме SQL, где каждая запись должна быть уникально идентифицируема. Я бы вообще запретил создавать таблицы без явно заданного ключа.
Ты не путай индекс, PK и парадигму.
"Парадигма" требует, чтобы в таблице был уникальный ключ (поле или набор полей однозначно идентифицирующие запись) — понятие сугубо эфемерное и ни какой физической реализации от сервера не требующее.
PK — условное название этого самого набора полей.
Индекс — внутренний механизм сервера облегчающий поиск нужной записи в таблице. В "парадигме" про индекс ни слова. Равно как и про то, что PK должен обязательно быть индексированым.
Здравствуйте, Mika Soukhov, Вы писали:
MS>Накопились вопросики и решил спросить здешних гуру
MS>1) Как можно удалить целиком таблицу, не удаляя каждую ее строки? Есть ли какой нить механизм?
MS>2) Что есть CUBE?
MS>3) alter меняют структуру уже существующих обектов. Где может понадобиться такой подход? Пока мне кажеться, что это всего лишь заплатка в проектировании.
MS>4) Primary key. Что физически несет под собой ключевое слово? Будет ли иметь существенную разницу, если я буду использовать просто MS>unique? Создаеться ли автоматом для этой колонки индекс?
MS>5) (соот к 4 п.) Для работы с индексированной таблицей мне достаточно создать индекс для нужной колонки и уже прозрачно работать с запросами (не заботясь о индексах, как будто их не существует). Почему же я не могу (вернее даже СУБД) автоматом на создавать для каждого поля по индексу? Все будет работать очень быстро и все будут счастливы. НО. Здравый смысл мне подсказывает, что бесплатный сыр бывает только в мышелвке. Где же подвох? Для каких размерностей таблиц лучше вводить индексы, а для каких нет?
MS>6) при создании таблицы, если поле указать как DEFAULT, гарантирует ли он NOT NULL? Или я же смогу проделать такой запрос "insert into ObsoleteTable VALUES(NULL, bla-bla-bla)"?
MS>7) можно ли исполльзовать операцию INSERT более одного раза? И если нет, то почему?
MS>8) Я этот вопрос уже задавал. Но не получил ответа. Поэтому, пользуясь случаем хочу: во-первых, передать привет маме, а во-вторых спросить еще раз. Где же разница между functions & procedures ?
1) Удаление таблицы — DROP TABLE, а если тебе надо удалить все записи или по-какому-либо условию, то
delete from имя_таблицы where условие.
2)CUBE — это общее название объемных баз данных, не обязательно куб.
3) Насчет ALTER ни разу не применял, хотя действие этой команды знаю, может ты и прав что это всего лишь заплатка в проектировании.
4) Primary key — это первичный ключ, и в зависимости в какой среде ты пишешь ПО, можно говорить об их плюсах или минусах, напиши конкретней где ты их хочешь использовать.
5) Во-первых ограничение есть, составной ключ может содержать только 10 полей кажеться, а минусы есть, физически файл содержащий такой ключ будет существенно большим.
6) Если указывать DEFAULT, то да это гарантирует, что по умолчанию будет присвоено именно то значение которое указано в DEFAULT.
Здравствуйте, Merle, Вы писали:
M>Здравствуйте, kulentsov, Вы писали:
M>>>Не, нельзя так народ путать... K>> Я не путаю. Просто я описываю generic ситуацию, а не MSSQL. Ближе к MySQL. M>Не, это не generic ситуация, а непонятно что. M>В generic, если вспомнить реляционную теорию, PK — уникальный идентификатор, про упорядоченность и все остальное там ни слова.
Это не теория, это практика. Моя, во всяком случае.
M>>>Так, вот здесь я чувствую надо порядок в умах наводить. Итак в дальнейшем у нас на повестке дня MSSQL. K>>... M>>>Если же мы строим по какому-нибудь полю/полям в таблице кластерный индекс, то каждой строке присваивается уникальный ключ и сами строки располагаются в том же порядке, что и записи в кластерном индексе. После этого отпадает необходимость пользоваться изнурительной комбинацией ID'шников для идентификации строки и все индексы начинают ссылаться на кластерный индекс. K>> ... что и является более общим случаем для баз данных. M>Тоесть? Что здесь является более общим случаем?
"отпадает необходимость пользоваться изнурительной комбинацией ID'шников". И эффект все-таки может иметь место для MS, как ты сам написал, или в других случаях просто имеет место, как в MyISAM таблицах.
M>>>И еще раз хочу напомнить, что объявление PK вовсе не означает создание кластерного индекса. K>> ... в MS SQL. В тех же MyISAM любой индекс в терминологии M$ получается "кластерный". M>Такого просто не может быть. Кластерный индекс, в терминологии MS, по определению может быть только один. Нельзя отсортировать одну таблицу одновременно двумя разными способами. Тогда это будут уже две таблицы.
А. Во всяком случае, не HEAP.
M>>>Мой опыт мне как раз подсказывает обратное. Проектировать базу надо так, чтобы не возникало необходимости в ad-hoc запросах, K>> Невозможно! M>Нет ничего невозможного, если с умом подходить, а не раскладывать индексы по углам, на всякий случай..
Ты не можешь иметь все возможные виды накопительной статистики, которые может теоретически пожелать пользователь.
... M>>>А вот бездумное пихание индексов куда попало, как правило приводит к конкретным тормозам. Выбор же кластерного K>> ... в MS SQL опять же, наверное. Меня это всегда удивляло. M>Что именно? Что выбор индекса штука не тривиальная?
Нет, что добавление данных может быть проблемой.
K>>Может, потому, что у меня еще не было проектов, где данные апдейтились бы чаще, чем использовались для выборок. M>А чаще и не обязательно. Достаточно пары десятков процентов, чтобы в серьез задуматься о потребности содержать индексы "про запас".
Ого, как все запущено. Кажется, моя политика избегания продуктов MS везде, где только можно, подтверждается в очередной раз.
M>>>индекса — это вообще стратегический вопрос, кластерный индекс по PK в большинстве случаев лучше чем ничего, и поэтому тут сервер проявляет некоторое самоуправство приходя на помощ неопытному разработчику, но это далеко не всегда оптимальное решение. K>> По мне так это очень простой вопрос. Если у нас "ничего", это просто несоответствие парадигме SQL, где каждая запись должна быть уникально идентифицируема. Я бы вообще запретил создавать таблицы без явно заданного ключа. M>Ты не путай индекс, PK и парадигму. M>"Парадигма" требует, чтобы в таблице был уникальный ключ (поле или набор полей однозначно идентифицирующие запись) — понятие сугубо эфемерное и ни какой физической реализации от сервера не требующее. M>PK — условное название этого самого набора полей. M>Индекс — внутренний механизм сервера облегчающий поиск нужной записи в таблице. В "парадигме" про индекс ни слова. Равно как и про то, что PK должен обязательно быть индексированым.
А я и не путаю. Но только так уж повелось в SQL, что мы указываем уникальность записей путем именно задания индексов. Т.е. я ставлю знак равенства между уникальностью поля/полей и наличием уникального/главного ключа.
Здравствуйте, kulentsov, Вы писали:
K>Т.е. я ставлю знак равенства между уникальностью поля/полей и наличием уникального/главного ключа.
и напрасно... далеко не всегда это именно так.
... << RSDN@Home 1.1 beta 1 >>
— сколько программистов надо чтобы заменить сгоревшую лампочку?
— сколько не бери, а лампочку не поменять — проблема аппаратная, программным путем не решается...
Здравствуйте, kulentsov, Вы писали:
K> Это не теория, это практика. Моя, во всяком случае.
Кхм... Ладно, заканчиваем практиками меряться, а то некрасиво получается.
K> "отпадает необходимость пользоваться изнурительной комбинацией ID'шников". И эффект все-таки может иметь место для MS, как ты сам написал, или в других случаях просто имеет место, как в MyISAM таблицах.
Ты об каком эффекте? о кластерном индексе? Да может быть, а может и не быть, об чем и речь.
В оракле, например, аналогичная фича называется IOT (Index Ordered Table), и она тоже далеко не сама собой рождается...
M>>Нет ничего невозможного, если с умом подходить, а не раскладывать индексы по углам, на всякий случай.. K> Ты не можешь иметь все возможные виды накопительной статистики, которые может теоретически пожелать пользователь.
А мне и не надо их иметь. Вот когда пользователю они потребуются я нужную статистику и заведу. Но опять-таки распиханные во все места индексы мне здесь ни разу не помогут.
K>>> ... в MS SQL опять же, наверное. Меня это всегда удивляло. M>>Что именно? Что выбор индекса штука не тривиальная? K> Нет, что добавление данных может быть проблемой.
Enjoy. Две/три сотни более-менее активно пишущих пользователя возвратят тебя в реальный мир.
В качестве дополнительного приза каждому активному расставлятелю индексов дедлок в подарок.
K> А я и не путаю. Но только так уж повелось в SQL, что мы указываем уникальность записей путем именно задания индексов.
Ээээ.. Тогда расшифруй пожалуйста, что есть SQL. Похоже мы вообще о разных вещах говорим.
Уникальность с индексом очень мало связана. Уникальность — это ограничение целостности, задаваемое, как правило, логикой приложения. Индекс, как уже было сказано, внутренний механизм сервера обеспечивающий эффективность поиска.
И то, что обычно индекс по уникальному полю оказывается эффективнее, никакого отножения к делу не имеет.
K>Т.е. я ставлю знак равенства между уникальностью поля/полей и наличием уникального/главного ключа.
Смело.
Здравствуйте, Merle, Вы писали:
K>> "отпадает необходимость пользоваться изнурительной комбинацией ID'шников". И эффект все-таки может иметь место для MS, как ты сам написал, или в других случаях просто имеет место, как в MyISAM таблицах. M>Ты об каком эффекте? о кластерном индексе? Да может быть, а может и не быть, об чем и речь. M>В оракле, например, аналогичная фича называется IOT (Index Ordered Table), и она тоже далеко не сама собой рождается...
О более быстрой выборке по Primary key. Вообще-то, если отлистать назад, я нигде не говорил, что "во всех случаях". :-| Ясен пень, что не всегда.
M>>>Нет ничего невозможного, если с умом подходить, а не раскладывать индексы по углам, на всякий случай.. K>> Ты не можешь иметь все возможные виды накопительной статистики, которые может теоретически пожелать пользователь. M>А мне и не надо их иметь. Вот когда пользователю они потребуются я нужную статистику и заведу. Но опять-таки
... а в процессе заведения её и потребуются ad-hoc запросы.
M>распиханные во все места индексы мне здесь ни разу не помогут.
... и распиханные индексы как раз тут и помогут. Тем более что накопительная статистика требует дополнительной логики, и пока ты будешь её реализовывать, может потребоваться пока вывесить страничку, считающую все это "в лоб".
K>>>> ... в MS SQL опять же, наверное. Меня это всегда удивляло. M>>>Что именно? Что выбор индекса штука не тривиальная? K>> Нет, что добавление данных может быть проблемой. M>Enjoy. Две/три сотни более-менее активно пишущих пользователя возвратят тебя в реальный мир. M>В качестве дополнительного приза каждому активному расставлятелю индексов дедлок в подарок.
Не думаю. Против дедлока у нас есть такие не вчера придуманные вещи, как журнальные таблицы, в которых (сюрприз!) операция добавления ничего не блокирует. В приложении к моей конкретике борьба будет выглядеть как ALTER TABLE Type=InnoDB один раз.
K>> А я и не путаю. Но только так уж повелось в SQL, что мы указываем уникальность записей путем именно задания индексов. M>Ээээ.. Тогда расшифруй пожалуйста, что есть SQL. Похоже мы вообще о разных вещах говорим.
Я — о языке SQL, а ты о чем? M>Уникальность с индексом очень мало связана. Уникальность — это ограничение целостности, задаваемое, как правило, логикой приложения. Индекс, как уже было сказано, внутренний механизм сервера обеспечивающий эффективность поиска. M>И то, что обычно индекс по уникальному полю оказывается эффективнее, никакого отножения к делу не имеет.
Этого достаточно для иллюстрации моей мысли? Надеюсь, источник указывать не надо.
K>>Т.е. я ставлю знак равенства между уникальностью поля/полей и наличием уникального/главного ключа. M>Смело.
Уж такой я. Возможно, я чего-то не знаю и существуют базы, которые обеспечивают уникальность поля _без_ заведения индекса по нему. Тогда просветите — пополню свою коллекцию софта, которым нельзя пользоваться.
Сейчас резюмирую для себя этот тред.
Я по-прежнему считаю, что дал начинающему совершенно правильный совет. Так как нормальная ситуация — когда добавление/модификация данных занимают проценты либо даже какие-то доли процента от общей загрузки сервера. Приведенный пример с сотнями пишущих пользователей меня не убеждает. Я как-то собирал статистику по своему форуму — получается более 40 показов на письмо, и думаю, эта статистика типична. То есть если при таком разкладе добавление (пусть 1/40 = 2.5 процента операций) начинает занимать десятки процентов, то тут не в индексах вопрос, тут какое-то глубокое "не то" с архитектурой вообще, надо либо что-то кардинально переписывать, либо SQL сервер на нормальный менять.
Дополнительный момент — количество индексированных полей. В типичном приложении без всякого "разбрасывания по углам", только необходимых индексов — по большинству полей. Я бы даже сказал — по подавляющему большинству. То есть вот сделал он базу, внедрил её, наделал статистики, расставил индексов где надо, и есть таблица с двенадцатью полями, из которых девять индексированных. И другой вариант: сделал базу, сразу всё оптом проиндексировал, потом всё остальное, и получилась там таблица с двенадцатью индектированными полями вместо девяти. Ну, и кто это заметит? Ответ "Merle с профайлером" не принимается. И главное — стоят ли эти копейки разборок с логом запросов и выяснением, кому какого индекса там не хватает?
Здравствуйте, kulentsov, Вы писали:
M>>В оракле, например, аналогичная фича называется IOT (Index Ordered Table), и она тоже далеко не сама собой рождается... K> О более быстрой выборке по Primary key. Вообще-то, если отлистать назад, я нигде не говорил, что "во всех случаях". :-| Ясен пень, что не всегда.
Ну как бы да, теоретически если таблицу отсортировать по PK, то выборка по нему будет быстрее. Но если мне вообще не нужно делать выборку по PK? Тоже будем по нему индекс создавать? И таблицу по нему сортировать тоже будем?
M>>А мне и не надо их иметь. Вот когда пользователю они потребуются я нужную статистику и заведу. Но опять-таки K> ... а в процессе заведения её и потребуются ad-hoc запросы.
Тоесть? Это будут уже не ad-hoc запросы, а вполне себе регулярные и укладывающиеся в спроектированную и перепроектированную архитектуру. Когда я буду их пускать база уже будет под них перенастроена.
K> ... и распиханные индексы как раз тут и помогут. Тем более что накопительная статистика требует дополнительной логики, и пока ты будешь её реализовывать, может потребоваться пока вывесить страничку, считающую все это "в лоб".
Вот за подсчеты в лоб и надо бить по рукам, один такой запрос может любую систему колом поставить, за исключением версионной. Но это отдельная песня, спроблемы с ad-hoc запросами, пожалуй самый серьезный недостаток блокировочников.
Возвращаясь к нашей проблеме, опять-таки построить индекс — пятиминутное шевеление пальцами, вто время как развешивание их где попало — черевато боком...
Как ты думаешь, почему сервер при создании таблицы сам не распихивает индексы везде где можно?
M>>Enjoy. Две/три сотни более-менее активно пишущих пользователя возвратят тебя в реальный мир. M>>В качестве дополнительного приза каждому активному расставлятелю индексов дедлок в подарок. K> Не думаю. Против дедлока у нас есть такие не вчера придуманные вещи, как журнальные таблицы, в которых (сюрприз!) операция добавления ничего не блокирует. В приложении к моей конкретике борьба будет выглядеть как ALTER TABLE Type=InnoDB один раз.
Ага, сюрприз будет у DBA, когда транзакция прочитает не согласованные данные, а потом куда-нибудь запишет. Концов не найдешь.
Вот тогда тебе, как разработчику, спасибо и скажут.
K>
K> Этого достаточно для иллюстрации моей мысли?
Какой? Где здесь создание индекса?
K>>>Т.е. я ставлю знак равенства между уникальностью поля/полей и наличием уникального/главного ключа. M>>Смело. K> Уж такой я. Возможно, я чего-то не знаю и существуют базы, которые обеспечивают уникальность поля _без_ заведения индекса по нему. Тогда просветите — пополню свою коллекцию софта, которым нельзя пользоваться.
Записывай: MSSQL, Oracle, DB2, Informix, Sybase... достаточно?
K>Я по-прежнему считаю, что дал начинающему совершенно правильный совет. Так как нормальная ситуация — когда добавление/модификация данных занимают проценты либо даже какие-то доли процента от общей загрузки сервера. Приведенный пример с сотнями пишущих пользователей меня не убеждает. Я как-то собирал статистику по своему форуму — получается более 40 показов на письмо, и думаю, эта статистика типична. То есть если при таком разкладе добавление (пусть 1/40 = 2.5 процента операций) начинает занимать десятки процентов, то тут не в индексах вопрос, тут какое-то глубокое "не то" с архитектурой вообще, надо либо что-то кардинально переписывать, либо SQL сервер на нормальный менять.
Совет ты дал совершенно не верный.
Вопервых речь шла именно об MSSQL.
Во вторых, ты забываешь, что MySQL, на который ты очень часто ссылался
а) Вовсе не является образцом реляционной базы, хотя бы в силу весьма посредственной поддержки SQL и ACIDity транзакций, что имеет непосредственное отношение к вопросу.
б) В силу пункта а. предназначен для достаточно узкого круга задач, а значит опять-таки не может служить примером для иллюстрации рассуждений "в общем виде"
В третьих Web приложение опять таки не аргумент, так как это еще более узкий класс задач.
K> Дополнительный момент — количество индексированных полей. В типичном приложении без всякого "разбрасывания по углам", только необходимых индексов — по большинству полей. Я бы даже сказал — по подавляющему большинству.
А вот это очень серьезное заблуждение.
Таблицы с сотней полей вполне нормальное явление, и если по большинству построить индексы, то мало не покажется.
K> То есть вот сделал он базу, внедрил её, наделал статистики, расставил индексов где надо, и есть таблица с двенадцатью полями, из которых девять индексированных. И другой вариант: сделал базу, сразу всё оптом проиндексировал, потом всё остальное, и получилась там таблица с двенадцатью индектированными полями вместо девяти. Ну, и кто это заметит? Ответ "Merle с профайлером" не принимается. И главное — стоят ли эти копейки разборок с логом запросов и выяснением, кому какого индекса там не хватает?
Ага, а когда таблиц больше сотни и в некоторых полей штук по пятьдесят? Тоже все индексировать?
Похоже мы просто о задачах разного уровня говорим...
У вас такой горячий спор, что влазить в ваш разговор сначало не хотелось.
Ключ по Primary Key можно создать максимум по 16 полям, но на счет даже 8 или 10 надо серьезно подумать есть ли в этом большая необходимость. У меня был всего один случай когда я делал Primary Key по 9 полям, но там просто мне это было необходимо. Если же можно обойтись, то лучше такого не делать. И вообще ключи я создаю только для уникальности и целостности данных, если же в таблице нет уникальности, то я создаю спец.поле и делаю на него ключ.
Здравствуйте, Merle, Вы писали:
M>Здравствуйте, kulentsov, Вы писали:
M>>>В оракле, например, аналогичная фича называется IOT (Index Ordered Table), и она тоже далеко не сама собой рождается... K>> О более быстрой выборке по Primary key. Вообще-то, если отлистать назад, я нигде не говорил, что "во всех случаях". :-| Ясен пень, что не всегда. M>Ну как бы да, теоретически если таблицу отсортировать по PK, то выборка по нему будет быстрее. Но если мне вообще не нужно делать выборку по PK? Тоже будем по нему индекс создавать? И таблицу по нему сортировать тоже будем?
Это.. Ты прежде чем отвечать, порядок в голове наводи, а то ерунду писать начинаешь. Перечитай начало. Скорость выборки по PK — это один вопрос, который тут обсуждали, а расстановка индексов — совсем другой вопрос, никаким боком не относящийся к первому.
M>>>А мне и не надо их иметь. Вот когда пользователю они потребуются я нужную статистику и заведу. Но опять-таки K>> ... а в процессе заведения её и потребуются ad-hoc запросы. M>Тоесть? Это будут уже не ad-hoc запросы, а вполне себе регулярные и укладывающиеся в спроектированную и перепроектированную архитектуру. Когда я буду их пускать база уже будет под них перенастроена.
Ты упорно не понимаешь, о чем я пишу. Понимаешь, есть такая информация, для получения которой нам либо надо _с самого_ начала предусмотреть статистику для неё (что для всех случаев невозможно, как я писал), либо пускать запрос по всей базе. Можешь называть это "перенастройкой базы", если хочешь, суть не изменится.
M>Как ты думаешь, почему сервер при создании таблицы сам не распихивает индексы везде где можно?
Я думаю, потому что правильный путь для сервера заключается в другом. При каждом запросе он составляет список индексов, которые ему нужны, и смотрит, какие из них есть, чтобы их использовать. Если каких-то не хватает, то создаются временные данные, которые помогают ему выполнить запрос — индекс в памяти, что-то еще, неважно. Важно то, что после запроса они чикаются, что и есть ошибка. Надо недостающие индексы просто автоматически создавать в базе. Тогда человеку вообще не надо будет думать об индексах (чего мы и добиваемся), а заниматься собственно данными.
M>>>Enjoy. Две/три сотни более-менее активно пишущих пользователя возвратят тебя в реальный мир. M>>>В качестве дополнительного приза каждому активному расставлятелю индексов дедлок в подарок. K>> Не думаю. Против дедлока у нас есть такие не вчера придуманные вещи, как журнальные таблицы, в которых (сюрприз!) операция добавления ничего не блокирует. В приложении к моей конкретике борьба будет выглядеть как ALTER TABLE Type=InnoDB один раз. M>Ага, сюрприз будет у DBA, когда транзакция прочитает не согласованные данные, а потом куда-нибудь запишет. Концов не найдешь.
Это где так — в MS SQL, что ли? В нормальных серверах добавления не только ничего не блокируют, но и видны становятся остальным тредам все сразу когда надо — в конце транзакции.
M>Вот тогда тебе, как разработчику, спасибо и скажут.
Предпочитаю наличность.
K>>
K>> Этого достаточно для иллюстрации моей мысли? M>Какой? Где здесь создание индекса? На диске, мой друг, на диске!
K>>>>Т.е. я ставлю знак равенства между уникальностью поля/полей и наличием уникального/главного ключа. M>>>Смело. K>> Уж такой я. Возможно, я чего-то не знаю и существуют базы, которые обеспечивают уникальность поля _без_ заведения индекса по нему. Тогда просветите — пополню свою коллекцию софта, которым нельзя пользоваться. M>Записывай: MSSQL, Oracle, DB2, Informix, Sybase... достаточно?
"Век живи — век учись" — сказал порутчик Ржевский. Сказав "А", скажи и "Б":
1. Какой командой мы обеспечиваем уникальность столбца без заведения индекса по нему?
2. Как база данных реализует проверку на уникальность без индекса?
3. раз уж мы тут — зачем это нужно? Какие преимущества по сравнению со случаем уникального индекса?
M>Совет ты дал совершенно не верный. M>Вопервых речь шла именно об MSSQL.
Да, вернее было бы сказать "Переползай на Оракл".
M>Во вторых, ты забываешь, что MySQL, на который ты очень часто ссылался M>а) Вовсе не является образцом реляционной базы, хотя бы в силу весьма посредственной поддержки SQL и ACIDity транзакций, что имеет непосредственное отношение к вопросу.
SQL — да, транзакции — нет. Читайте новости, которые уже давно не новости (про альтернативные типы таблиц).
M>б) В силу пункта а. предназначен для достаточно узкого круга задач, а значит опять-таки не может служить примером для иллюстрации рассуждений "в общем виде"
Ерунда полная. Неразвитость SQL легко замещается, а надежность и масштабируемость MySQL выше всяких похвал. А заодно и переносимость. После появления InnoDB у Оракла появилась проблема. Этого еще не видно, но думаю, когда MySQL AB поработает над языком в достаточной степени, это проявится.
M>В третьих Web приложение опять таки не аргумент, так как это еще более узкий класс задач.
Ничего такого специфичного именно для веба я не утверждал.
K>> Дополнительный момент — количество индексированных полей. В типичном приложении без всякого "разбрасывания по углам", только необходимых индексов — по большинству полей. Я бы даже сказал — по подавляющему большинству. M>А вот это очень серьезное заблуждение. M>Таблицы с сотней полей вполне нормальное явление, и если по большинству построить индексы, то мало не покажется.
... M>Ага, а когда таблиц больше сотни и в некоторых полей штук по пятьдесят? Тоже все индексировать? M>Похоже мы просто о задачах разного уровня говорим...
Ну крут, крут. Но аргумент мимо тазика. Потому что спрашивающий еще не достиг такого уровня, чтобы писать приложения с сотнями таблиц. А когда достигнет — у него просто не будет возникать подобных вопросов. А тормозные запросы в результате отсутствия индексов появятся у него гоораздо раньше.
Теперь о самой ситуации. Не, ребята... Сотни таблиц? С сотнями полей? ТЫСЯЧИ ИЛИ ДЕСЯТКИ ТЫСЯЧ ПОЛЕЙ, НАБИТЫЕ ВРУЧНУЮ АВТОРОМ ПРИЛОЖЕНИЯ? Это — нормально? Это — АБнормально. Это просто абзац какой-то. Это полное неумение проектировать и как следствие — решение задач негодными средствами. Это всё равно что иметь пару сотен параметров в приложении и вместо того, чтобы сделать из них массив или коллекцию, заводить для каждой свою переменную.. Это нормально для 10-20 переменных, но не для 100. Когда у меня задачи начали грозить количеством полей за 20-30, я их стал унифицировать в отдельных таблицах, а когда с количеством классов объектов началась подобная беда, я перешёл на объектную базу. Чего и другим желаю.
Здравствуйте, kulentsov, Вы писали:
K> Скорость выборки по PK — это один вопрос, который тут обсуждали, а расстановка индексов — совсем другой вопрос, никаким боком не относящийся к первому.
Вот именно об этом я и говорю...
K> Ты упорно не понимаешь, о чем я пишу. Понимаешь, есть такая информация, для получения которой нам либо надо _с самого_ начала предусмотреть статистику для неё (что для всех случаев невозможно, как я писал), либо пускать запрос по всей базе. Можешь называть это "перенастройкой базы", если хочешь, суть не изменится.
Нет, это ты не понимаешь..
Индекс — вовсе не есть та самая статистика, точнее он только часть необходимой статистики, причем далеко не самая важная.
M>>Как ты думаешь, почему сервер при создании таблицы сам не распихивает индексы везде где можно? K> Я думаю, потому что правильный путь для сервера заключается в другом. При каждом запросе он составляет список индексов, которые ему нужны, и смотрит, какие из них есть, чтобы их использовать. Если каких-то не хватает, то создаются временные данные, которые помогают ему выполнить запрос — индекс в памяти, что-то еще, неважно. Важно то, что после запроса они чикаются, что и есть ошибка.
А вот теперь ты расскажи мне какие сервара так делают, чтобы я знал, чем пользоваться не стоит. MySql?
K>Надо недостающие индексы просто автоматически создавать в базе.
Индексы надо создавать только необходимые. Ни больше не меньше.
Собственно это и есть основной и принципиальный вопрос наших разногласий. Может быть для MySql'я твой подход и годится, но ни для MSSQL'я, ни для Oracle'а, ни для DB2, ни для любого другого полноценного реляционного сервера БД так делать нельзя.
Во первых вариантов индекса может быть гораздо больше, чем возможных полей. Иногда нужны составные индексы, покрывающие, для ряда запросов и т.д. Ты предлагаешь создавать все возможные варианты просто на всякий случай?
Во вторых создавая индексы сверх необходимого ты полностью теряешь возможность управлять ходом выполнения запроса, что может привести к весьма печальным последствиям.
M>>Ага, сюрприз будет у DBA, когда транзакция прочитает не согласованные данные, а потом куда-нибудь запишет. Концов не найдешь. K> Это где так — в MS SQL, что ли? В нормальных серверах добавления не только ничего не блокируют, но и видны становятся остальным тредам все сразу когда надо — в конце транзакции.
Угу. Расскажи мне пожалуйста про такой феномен, как Phantom Read, про известные способы борьбы с ним и про преимущества и недостатки этих способов.
Вот тогда и поговорим, предметно...
А так же, что это за "нормальные сервера" и что ты понимаешь под термином "нормальный сервер"?
Да и в конце какой транзакции они становятся видны? Тоже очень любопытно.
K>1. Какой командой мы обеспечиваем уникальность столбца без заведения индекса по нему?
UNIQUE.
K>2. Как база данных реализует проверку на уникальность без индекса?
Зависит от внутреннего механизма.
Но индекс и уникальность — не муж и жена, а четыре разных человека.
K>3. раз уж мы тут — зачем это нужно? Какие преимущества по сравнению со случаем уникального индекса?
Целостность гарантируется, но нет накладных расходов на поддержание индекса.
M>>Вопервых речь шла именно об MSSQL. K> Да, вернее было бы сказать "Переползай на Оракл".
Вернее было бы промолчать. Или по крайней мере не ссылаться на "общий случай". Сказал бы, что "В MySql'е надо создавать все индексы, какие только можно..." И ни кто и слова бы против не сказал. Если это действительно так.
M>>Во вторых, ты забываешь, что MySQL, на который ты очень часто ссылался M>>а) Вовсе не является образцом реляционной базы, хотя бы в силу весьма посредственной поддержки SQL и ACIDity транзакций, что имеет непосредственное отношение к вопросу. K> SQL — да, транзакции — нет. Читайте новости, которые уже давно не новости (про альтернативные типы таблиц).
Про поддержку транзакций я слышал, а так же и про то, что она весьма далека от совершенства. Насколько я помню там содрали механизм concurrency c BerklyDB, которая далеко не образец для подражания в этом плане.
M>>б) В силу пункта а. предназначен для достаточно узкого круга задач, а значит опять-таки не может служить примером для иллюстрации рассуждений "в общем виде" K> Ерунда полная. Неразвитость SQL легко замещается, а надежность и масштабируемость MySQL выше всяких похвал.
Ага. Масштабируемость еще пожалуй потянет, а вот по поводу надежности лучше не надо, и по поводу поддержки транзакций тоже.
Вообще MySql весьма вольно обходится со стандартами и теорией которой ты здесь оперировал, поэтому ссылаться на него по меньшей мере не корректно.
И опять-таки не надо мешать в одну кучу теорию и конкретные реализации.
K>А заодно и переносимость. После появления InnoDB у Оракла появилась проблема. Этого еще не видно, но думаю, когда MySQL AB поработает над языком в достаточной степени, это проявится.
Ну, я думаю еще лет пять-семь упорной работы и из MySql получится достойный сервер.... Только оно надо? Он на своем месте и так не плох.
M>>В третьих Web приложение опять таки не аргумент, так как это еще более узкий класс задач. K> Ничего такого специфичного именно для веба я не утверждал.
Тебя процитировать? "....Я как-то собирал статистику по своему форуму — получается более 40 показов на письмо, и думаю, эта статистика типична......"
Так вот форумы, вовсе не являются типичной OLTP задачей.
K> Ну крут, крут. Но аргумент мимо тазика. Потому что спрашивающий еще не достиг такого уровня, чтобы писать приложения с сотнями таблиц. А когда достигнет — у него просто не будет возникать подобных вопросов.
Надо сразу учить, как делать правильно.
K> А тормозные запросы в результате отсутствия индексов появятся у него гоораздо раньше.
Не появятся. Чтобы индексами пользоваться надо для начала чего-нибудь про них прочитать, а не распихивать везде где можно. А если появятся, спросит — объясним.
Мы уже победили, просто это еще не так заметно...
Неужели я не знаю, сколько я не знаю сколько столбцов мне должно вернуться...
По нему записи сортируются физически. То есть в полностью оптимизированной таблице последовательный доступ по Primary последовательности теоретически быстрее, чем по другим ключам. Когда нам нужна вся запись, а не только ключ.
