> В MSSQL - нет. Всё, универсальности уже нет. Специфика. И в MySQL,
> и в PGSQL, и в Oracle.MSSQL - это своя атмосфера. В остальных есть.
> Не всегда. Есть примеры, но приводить лениво - ибо они объёмистые.
Хорошо в большинстве случаев.
> Мы же о специфике и говорили? Ее надо учитывать, если хочется получить
> результат выше среднего в сложных условиях и по пересеченной местности. Если
> средний или около того - то сойдёт что угодно.
Все вами перечисленное может быть уже сделано по месту. Лучше уделить больше внимания проектированию самой базы и архитектуры программы.
> Имеет, поскольку само приложение должно знать о партиционировании, и запросы могут вполне
> быть написаны с учётом оного.
Вот приложение про партицирование знать особо ничего не должно. Его просто делают под типичные запросы.
> Имеет, причём 100%.
Не имеет так-как может быть добавлено после разработки приложения. И указывать в приложении использовать вот этот индекс не нужно и часто вообще вредно. Из-за этого к примеру нет хинтов в PostgreSQL.
> Сделать, чтобы потом переделывать в боевой эксплуатации - не важно, апгрейдом или
> как ещё, в любом случае шанс ошибки возрастает. Подход, несовместимый со
> стабильностью, увы.
Вполне совместимый если у вас нормально спроектирована СУБД.
> Если он по фичам лучше всего - то это не "хреновое решение"?
Хреновое, так-как можно сделать и оптимальнее.
> Да, оно может и ужасно по коду, но при этом оно
> минимально "хреновое" из всех доступных. Остальные еще хуже. Большые "энтерпрайзные" тоже,
> в общем, не блещут - ресурсов им надо немеряно.
С ПО вообще все сложно. Отличные приложения встречаются, но редко.
> Не столкнулись на практике. В TokuDB проблем с записью особых нет. Да
> и в InnoDB их нет, если не злоупотреблять столбцами и индексами,
> и сознательно строить базу с максимальным обходом блокировок.
В TokuDB не будет. А вот в InnoDB сталкивался, правда это было года три назад, там еще у InnoDB были серьезные проблемы с масштабируемостью.
> Кстати, можно размер Вашей инсталляции (итемы/триггеры)? Просто для сравнения, комментировать
> не буду.
Да где-то как у вас.
> Это не из-за какой-либо проблемы в MySQL. Это из-за того, что ребятки
> обрабатывают по 1 элементу за 1 раз, хотя можно было оптом
> обработать пару десятков тысяч. В 2.0 вроде-бы как-то с этим справились,
> может действительно оптовую обработку сделали. Детально HK в 2.0 не смотрел
> - но его вообще в статистике не видно.
Да нет удаляли они уже тогда пачками. Но это плохо сказывалось на работу записи.
> У нас ситуация иная. Колом вставало именно чтение, причем записи в этот
> момент не было. Несколько переписанных запросов - и больше колом не
> встает ничего.
Ну черт знает. Я только могу резюмировать, что после перехода на PostgreSQL про прыганья вокруг СУБД шоб работало я забыл.
