Для чего нужна ORM?

Не согласен по многим пунктам. Хотя сталкивался с Enterprise-проектами неоднократно.
Правда, не c Java в качестве языка.
Может быть именно поэтому нет необходимости работать со всем как с объектом.

Для чего нужна ORM?

Удалили поле из таблицы

Нормальная СУБД проверит зависимости и инвалидирует пакеты/процедуры.

Переименование поля

Переименование поля в СУБД, где SQL позволяет делать alias'ы вообще не понятно зачем нужно.

Не самая высокая оптимальность запросов через ORM частично компенсируется возможностью кэширования

Большинство СУБД кешируют и сами запросы, и данные, которые они возвращают. Не уверен, что разработчик средней руки реализует какой-нибудь LRU механизм лучше, чем разработчики СУБД.

переносимость на другие БД

Гы-гы-гы, когда у вас в крупном проекте возникнет такая задача, это скорее всего будет означать, что пора выкидывать ORM и начинать закупать железо. Менять хранилище данных от нечего делать — глупо, а при проблемах означает, скорее всего, то, что придется отказаться от плюшек ORM и начать работать с напильником

Для чего нужна ORM?

И посмотрим, можно ли этот код сделать лучше при помощи ORM.

«Лучше» — это как? Быстрее? Читабельнее?

Для чего нужна ORM?

Это модификация единственного кажущегося более-менее адекватным ответа на вопрос: «При переходе проекта на новую СУБД не придется переписывать код». Правда, обычно его приводят как аргумент люди, которым не доводилось подобное действие совершать. Либо которые имеют слабое представление о возможностях той или иной СУБД.

Так вот — при подходе к работе с базой как к чуть более сложному механизму, чем просто хранилище, становится понятно, что даже SQL-синтаксис похож лишь в базовых конструкциях. И отдавать на откуп ORMу даже конструирование запросов — зачастую смерти подобно. Сильно сомневаюсь, что без знания о том, какие у меня данные ORM адекватно сможет определить какую из подобных конструкций нужно использовать в том или ином случае:

SELECT id FROM foo ORDER BY bar;

SELECT /*+index_asc(foo_bar_id) */ FROM foo;

SELECT * FROM foo WHERE rownum <= 10;

SELECT * FROM ( SELECT f.*, rownum rn FROM foo f ORDER BY id ) WHERE rn <= 10;

SELECT f.*, row_number() over (ORDER BY id) rn FROM foo f HAVING rn <= 10;

Проверки в триггерах MySQL

А, да. И про MyISAM тоже забудьте, если речь идет о обеспечении транзакционной целостности

Организация хранения структуры категорий в реляционной БД?

Для хранения 100000 категорий нужны числа от 00000 до 99999.
Это пятизначное число. Поэтому использовал пятерку.
Будет меньше категорий — используйте меньшую разрядность

Вот пример:
name____id____path

shop_____0____0000
category__1____00000001
бытовая__2____000000010002
аудио____3____0000000100020003
видео____4____0000000100020004

substr('0000000100020004', -4 ) = '0004';

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

Организация хранения структуры категорий в реляционной БД?

Для быстрого поиска храните в пути еще и id конечной категории.
Откусили последнее значение — получили ID, быстро его нашли без всяких там плясок с бубнами.
Если для хранения пути будете использовать не разделители, а числа фиксированной длины, то получите дополнительные бенефиты, когда путь нужного уровеня категорий вычисляется банальным substr(path, 1, 5*var_level), а последний ID substr(path, -5). Более того, если хранить таким образом, то путь будет уникальным, значит, его можно сделать примари ключом, тогда доступ по like будет еще быстрее.

Не парьтесь насчет размера, диски сейчас дешевые, а список много места не займет.
Я так храню примерно 40 миллионов комментариев, ни с производительностью, ни с местом проблем нет.

MySQL и оперирование с рейтингом игроков

С чего бы score быть уникальным, чтобы стать первичным ключем?
У двух пользователей не может быть одинакового количества баллов?

InnoDB как раз в силу транзакционности даст корректный ответ при уровне изоляции, отличном от READ UNCOMMITED. Только надо понимать на какой момент времени этот ответ будет корректным. MyISAM на моей памяти частенько выдавал разные значения для select (*) и select(id). Особенно, если давно не анализировался. Надо понимать, откуда MyISAM берет данные о количестве и почему они могут быть некорректными.

MySQL и оперирование с рейтингом игроков

Чо-чо-чо, какой такой primary key на неуникальном наборе данных?
Ну и range скан даже на партиционированных данных или даст неточное число (превед, myISAM), или будет достаточно медленным.