Накопились вопросики и решил спросить здешних гуру
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 с профайлером" не принимается. И главное — стоят ли эти копейки разборок с логом запросов и выяснением, кому какого индекса там не хватает?
Мы уже победили, просто это еще не так заметно...
Неужели я не знаю, сколько я не знаю сколько столбцов мне должно вернуться...
По нему записи сортируются физически. То есть в полностью оптимизированной таблице последовательный доступ по Primary последовательности теоретически быстрее, чем по другим ключам. Когда нам нужна вся запись, а не только ключ.
