Здравствуйте, 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>И то, что обычно индекс по уникальному полю оказывается эффективнее, никакого отножения к делу не имеет.

<unique constraint definition> ::=
<unique specification> (<unique column list>)
<unique specification> ::=
UNIQUE | PRIMARY KEY

Этого достаточно для иллюстрации моей мысли? Надеюсь, источник указывать не надо.

K>>Т.е. я ставлю знак равенства между уникальностью поля/полей и наличием уникального/главного ключа.
M>Смело.
Уж такой я. Возможно, я чего-то не знаю и существуют базы, которые обеспечивают уникальность поля _без_ заведения индекса по нему. Тогда просветите — пополню свою коллекцию софта, которым нельзя пользоваться.

Сейчас резюмирую для себя этот тред.
Я по-прежнему считаю, что дал начинающему совершенно правильный совет. Так как нормальная ситуация — когда добавление/модификация данных занимают проценты либо даже какие-то доли процента от общей загрузки сервера. Приведенный пример с сотнями пишущих пользователей меня не убеждает. Я как-то собирал статистику по своему форуму — получается более 40 показов на письмо, и думаю, эта статистика типична. То есть если при таком разкладе добавление (пусть 1/40 = 2.5 процента операций) начинает занимать десятки процентов, то тут не в индексах вопрос, тут какое-то глубокое "не то" с архитектурой вообще, надо либо что-то кардинально переписывать, либо SQL сервер на нормальный менять.
Дополнительный момент — количество индексированных полей. В типичном приложении без всякого "разбрасывания по углам", только необходимых индексов — по большинству полей. Я бы даже сказал — по подавляющему большинству. То есть вот сделал он базу, внедрил её, наделал статистики, расставил индексов где надо, и есть таблица с двенадцатью полями, из которых девять индексированных. И другой вариант: сделал базу, сразу всё оптом проиндексировал, потом всё остальное, и получилась там таблица с двенадцатью индектированными полями вместо девяти. Ну, и кто это заметит? Ответ "Merle с профайлером" не принимается. И главное — стоят ли эти копейки разборок с логом запросов и выяснением, кому какого индекса там не хватает?