т.к. там с помощью одного запроса можно сразу подсчитать кол-во найденного и получить все данные (т.е. экономия ресурсов сервера и пользователь меньше ожидает)
Это Вы с чего такую ерунду взяли? Гораздо больше ресурсов в данном случае БД будет тратиться на создание курсора.
Вообще почитайте для чего они нужны.
Количество найденного можно получить и с помощью pg_num_rows, можно и по другому(как минимум 2 варианта еще есть ).
Удалила уникальные индексы и поставила ваш индекс.
Тут смотрите. Если в Ваших запросах других используется правая часть индекса. То этот индекс использоваться не будет.
Терри пишет:
Это означает, что то, как я ставила уникальность, было неправильно и он рассматривал их по отдельности.
Абсолютно верно. Т.е запрос получался такой же как я и писал в втором ответе.
Терри пишет:
А этот составной индекс я должна именно командой ставить? Без галочек на соответствующую кнопку Unique?
Нет просто я написал запрос, так как таблица уже существует. Конечно проще ставить индексы при создании таблицы. Может и phpMyAdmin можно это сделать. Просто я с ним не работаю, поэтому не знаю (Знаю только как выполнить запрос SQL )
В таблице rimstype_name для значений id_lang, которые равны 2 и 3, он просто для них обновляет значения rimstype. А на id_rimstype совершенно не обращает внимания.
Он так и должен работать. У Вас стоят 2 индекса(ключа) оба уникальные. При совпадении любого из этих ключей (`id_rimstype` или `id_lang`) происходит
Коллеги, давайте избежим очередного бессмысленного холивара на тему ООП. Ну правда, сколько уже можно. Только на моей памяти на этом форуме подобных тем был с десяток, не меньше.
У каждого подхода своя область применимости, и кому как удобнее - пусть тот там и создает код.
Я только за. Действительно сама тема --->"холивар". Просто, очень многие, на форуме говорят что ООП - единственно верная стратегия . Вот я привел ссылку...
P.S Я абсолютно не против ООП. Просто надо понимать(уметь), использовать именно необходимые инструменты.