Здравствуйте, 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><unique constraint definition> ::=
K><unique specification> (<unique column list>)
K><unique specification> ::=
K>UNIQUE | PRIMARY KEY

K> Этого достаточно для иллюстрации моей мысли?
Какой? Где здесь создание индекса?

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


K>Я по-прежнему считаю, что дал начинающему совершенно правильный совет. Так как нормальная ситуация — когда добавление/модификация данных занимают проценты либо даже какие-то доли процента от общей загрузки сервера. Приведенный пример с сотнями пишущих пользователей меня не убеждает. Я как-то собирал статистику по своему форуму — получается более 40 показов на письмо, и думаю, эта статистика типична. То есть если при таком разкладе добавление (пусть 1/40 = 2.5 процента операций) начинает занимать десятки процентов, то тут не в индексах вопрос, тут какое-то глубокое "не то" с архитектурой вообще, надо либо что-то кардинально переписывать, либо SQL сервер на нормальный менять.
Совет ты дал совершенно не верный.
Вопервых речь шла именно об MSSQL.
Во вторых, ты забываешь, что MySQL, на который ты очень часто ссылался
а) Вовсе не является образцом реляционной базы, хотя бы в силу весьма посредственной поддержки SQL и ACIDity транзакций, что имеет непосредственное отношение к вопросу.
б) В силу пункта а. предназначен для достаточно узкого круга задач, а значит опять-таки не может служить примером для иллюстрации рассуждений "в общем виде"
В третьих Web приложение опять таки не аргумент, так как это еще более узкий класс задач.


K> Дополнительный момент — количество индексированных полей. В типичном приложении без всякого "разбрасывания по углам", только необходимых индексов — по большинству полей. Я бы даже сказал — по подавляющему большинству.
А вот это очень серьезное заблуждение.
Таблицы с сотней полей вполне нормальное явление, и если по большинству построить индексы, то мало не покажется.

K> То есть вот сделал он базу, внедрил её, наделал статистики, расставил индексов где надо, и есть таблица с двенадцатью полями, из которых девять индексированных. И другой вариант: сделал базу, сразу всё оптом проиндексировал, потом всё остальное, и получилась там таблица с двенадцатью индектированными полями вместо девяти. Ну, и кто это заметит? Ответ "Merle с профайлером" не принимается. И главное — стоят ли эти копейки разборок с логом запросов и выяснением, кому какого индекса там не хватает?
Ага, а когда таблиц больше сотни и в некоторых полей штук по пятьдесят? Тоже все индексировать?
Похоже мы просто о задачах разного уровня говорим...