miksoft,
опечатка, но "удачная"... клаву пора мыть - половина клавиш не прожимается.

denis2710, с чем предлагаете "разобраться че да как"? Просто не очень понял чего сказать хотели... вот, разбираюсь. ;)

Ежели с мускульными запросами, то там особо сложного ничего не бывает, потому как оптимизатор - убогий (и это - хорошо!), на крайняк - есть документация, на самый крайняк - этот форум. ;)

Гораздо хужее вумный (как вутка, тока не крякает) - оптимизатор. Ты предполагаешь одно, а он лепит - другое (например редукция неизменяемого подвыражения, которое тебе на самом деле "душу греет")...и главное молчит зараза (не крякает ведь)!

Ну например, где-нибудь в блоке WHERE ставишь IF(условие, LEAST( @one:="two", 1 ), 2)
, а он смотрит, что внутрях функции LEAST сплошь константы получаются и редуцирует вызов функции... да ишо и молча... бяда, ой бяда.

Не, в нормальных проектах вумные оптимизаторы - зло.

с какой из СУБД, "хорошо" - понятие растяжимое. Слегка знаком был с MS SQL Server особенно в части работы через MS Access-97...

"слегка" - это разработка только двух проектов с нуля и в одиночку:

1. Товарная СУБД для учета склада компьютерной фирмы с полуавтоматом по распознаванию "одинаковости" товарной позиции от разных поставщиков с элементами самообучения проги. Основной интерфейс оператора - MS Access, хранение MS SQL. Проект реализован в пилотной версии, и брошен по причине потери места работы по личным мотивам.

Собственно мой интерес к ИИ здесь и нарисовался...

2. Учет ТМЦ для издательства. Конкретно реализация первой версии, в виде переноса пилотного проекта с Мускула (ещё какой-то там 3-й версии MyIsam) на MS SQL... Проект также брошен по причине неспособности руководства издательства преодолеть саботаж руководителей среднего звена.

Вот уже третий год работаю на MySQL 5.1.48 ... и, как оценивается другими - знаю его виртуозно... но вот сам о себе такого сказать не могу. Хотя бы потому, что через запрос, в доку все равно лезешь. В браузере, не закрывается 4 вкладки: MySql, HTML, PHP, JQuery.
Это к тому, что "хорошо" - очень относительно.

SergSuper, беда - это когда программист вместо понимания чего и зачем он использует, пользуется чужим мнением без анализа.

denis2710,
ежели оптимизатор тупой, чего туды смотреть? ;)

В нормальном, развесистом проекте к каждой табличке идет не один запрос, и индексов там навешано как г...<вырезано самоцензурой>... много в общем. А то и по нескольку на одно поле. Нафига, заморачиваться и куда-то смотреть, когда можно тупо сказать какой конкретно именно тут нужен? ;)

Нет, конечно, когда оно откровенно тупит, есть смысл и в план заглядывать... я ж не говорю о том, что оно совсем лишнее.

Из прошлой жизни (исключительно как пример для понимания):

Долгое время ответственные вещи писал только на Ассемблерах, не доверяя "вумным оптимизаторам", за что был прозван в узком кругу "lastbyte" (в смысле код вылизан до последнего байта). И только после того, как Ватком С компилятор смог породить код длинной в 3 килобайта, практически совпадающий с моей писаниной "байт в байт", вплоть до выбора тех же регистровых групп и выкрутасов... в тогда начал писать всё на Сях... зная и понимая, что породит компилятор. Но, в своё время, это был лучший компилятор со всеми возможными оптимизациями.

Я это к чему: нормальному программисту оптимизатор, как таковой не нужен. Он сам оптимизатор. А начинающему, все равно не поможет, только запутает. Для простых вещей, да полезен. На то они и простые, там по большому счету "все равно".

Dimitry Sibiryakov, да, проекты из 200-500 таблиц, как-то норма. Если Вы работаете только с одной-двумя, то Вам это не надо.

Dimitry Sibiryakov, мне нравится ваш троллинг. Где нашли про "каждое" поле? При реализации по ТЗ - также фантазируете или только тут? ;)

Там було индексов ... многа, в том числе и по НЕСКОЛЬКУ НА ОДНО поле.

И, как вам правильно указали - во-первых каждый внешний ключ в InnoDeBiloid - индексируется. Это раз, а если мне нужны составные уникальные индексы (например для вставки) - это ОТДЕЛЬНЫЙ индекс, а если мне нужны полнотекстовые для выборок - это тоже ОТДЕЛЬНЫЙ индекс, а если в отдельных (и как правило тяжелых запросах) надо иметь поиск с группировкой, то приходится иметь и сюда индекс

... потому как без индексов, ни мускуль, ни какая другая БД не пашут, и сносно работают только если вся БД целиком лезет в память.

Кстати, а где вы видели проекты в 200-500 таблиц с небольшим количеством связей? У нас нормально джойнится от 5 до 20 таблиц.

Dimitry Sibiryakov, поздравляю, но там - нет этого.

И воббще, предлагаю прекратить троллинг. Тему ваще предлагаю закрыть, потому как ответ на поставленный вопрос дан и уже давно.

tanglir,

Во-первых, проекты такого размера, как правило, тянутся десятилетиями и там есть всё - и нормализованные и не очень и даже совсем не нормализованные куски данных. Сталкивался даже с сознательной денормализацией... под тем самым, любимым Paradox.
Смотря кто, с каким набором знаний/навыков/умений и опыта это ваял, насколько был ограничен по времени, зачем оно было нужно сначала и к чему это всё привело потом...

Во-вторых, в таких проектах, реально бывает по нескольку уникальных индексов (правильно в основном при денормализации), когда например, надо найти все письма, отправленные заданным комплектом отправителей, по заданной тематике (комбинации уникальны) в заданном диапазоне дат, а для другой выборки требуется выбрать письма, отправленные для комплекта получателей по тематикам (блин, опять уникальная комбинация...) и тоже в заданном диапазоне дат, например за последний год. И совсем неважно, как хранятся отправители, получатели и тематики писем - текстом или идентами из справочников... (например, переписка через портал покупателя с продавцом)... нормализовано (не знаю зачем - письмо оно и в африке письмо, места - хватает, выборка все равно по индексам)... и чё? Два уникальных индекса (ну не может одно письмо втыкаться повторно!) - вынь и положь. Да и быстрее должно быть как понимаю (структура индекса проще, не?).

Понятно, что на самом деле уникальны тройки отправитель-тематика-получатель, но нужны - пары.

В-третьих, абревиатура требует расшифровки.

tanglir, пример из реального проекту.
"Письмо" - минимально так и есть 4 поля: from, to, subject, date. Утрировано, тематика и есть subject. Комбинация полей from,to,subject - уникальна. Но также, уникальны и пары from-subject и to-subject, а вот пара from-to может иметь много разных subject. Вот об ентом и речь.

Когда надо из большой (достаточно) таблички выдрать данные - используются или тот или другой индекс. Почему не повесить на них признак уникальности? ИМХО, неуникальный индекс - должен быть всяко сложнее в своей структуре... а значит - дольше. Кстати, на практике, оба индекса были построены в порядке subject-to и subject-from... глюки оптимизатора - практически гарантированы. ;)
Авторство не моё, но столкнуться пришлось...

Можете обойтись одним индексом?

Пасибки за ссылку, не знал.