ponaehal

Есть всякие полезные функции определения NULL значения типа NVL/NVL2 (Oracle), но подозреваю, что в разных СУБД они реализованы по разному. И все равно общий смысл будет таким:

WHERE
        (tasks.project_id = ".$_SESSION['selected_menu_item_id']." 
AND tasks.author_id = '".$USER['id']."'")
OR (".$_SESSION['selected_menu_item_id']."  <b>is null</b>
AND tasks.author_id = '".$USER['id']."'")

Для того что бы понять/почувствовать язык SQL - вполне достаточно MySQL.
Как только изучите 4 основные команды DML и парочку команд DDL, можно задуматься о различиях и о конкретной платформе. Сугубо ИМХО.

Сей процесс называется транспонированием (см. тут). Делается он либо выражениями PIVOT/UNPIVOT, либо построением запроса типа

select group_concat(if(v='a', c, null)) a, 
       group_concat(if(v='b', c, null)) b, 
       group_concat(if(v='c', c, null)) c
  from (select value v, Count(value) c
          from t1
        group by value ) temp

Ну может еще как то можно...

Я считаю, что индексы добавлять нужно, ровно как и всевозможные ключи и ограничения.
1. Все это дает оптимизатору подсказку по правильному построению плана запроса.
2. Записи в таблице не упорядочены на диске. Если понадобится чтение с диска (если таблица не в памяти) для того что бы считать таблицу, может понадобиться много операций чтения. С индексом проще.
3. Отсутствие индексов по внешнему ключу может привести к блокировкам при вставке.
Понятно, что есть куча НО (по ситуации), но если затраты на добавление записи в индекс не критичны, то я за то что бы строить индексы и собирать статистику....

Хех... Не бывает абсолютно правильного ответа вне контекста решаемых задач.
Например, если необходимо часто эти данные извлекать, да еще и сортировкой (наверное нет необходимости объяснять разницу в порядке сортировки строковых и числовых значений), то Ваше текущее решение может оказаться наиболее правильным. Если значения всех характеристик упаковать в одно поле, то будут проблемы с извлечением, т.к. индекс по текстовому полю строить видимо бессмысленно (ввиду разнородности хранимой информации)
С другой стороны, если не планируете часто сортировать товары по значению одной из характеристик (например, по весу, габаритам), то и Бог бы с ним - делайте текстовое поле

ЗЫ Вот интересно что Вы такое пишите? Вроде бы уже куча интернет-магазинов написано под разные CMS. Ан нет, нужно сделать свое, родное....

Не силен в PHP, но вдруг подумалось что будет не айс если какой-нибудь доброжелатель в качестве id вам передаст строку вида: 1235" + "or 1=1" + ". ИМХО, надо бы как то залатать...

+ осторожнее использовать выражение LIKE
+ осторожнее с динамическим SQL

т.е. следить за теми значениями которые могут принимать переменные из которых вы лепите выражения like или динамический sql

Примерно так:

SELECT Max(max_fast_jackpot, max_coinflip_jackpot) 
FROM (
SELECT *,
       (SELECT Coalesce(Max(won_amount), 0)
        FROM   `fast_games`
               INNER JOIN `fast_bets` AS `winning_fast_bets`
                       ON `winning_fast_bets`.`id` =
                          `fast_games`.`winning_bet_id`
        WHERE  users.id = winning_fast_bets.user_id
               AND `fast_games`.`state` = ?)
       AS `max_fast_jackpot`,
       (SELECT Coalesce(Max(won_amount), 0)
        FROM   `coinflip_games`
               INNER JOIN `coinflip_bets` AS `winning_coinflip_bets`
                       ON `winning_coinflip_bets`.`id` =
                          `coinflip_games`.`winning_bet_id`
        WHERE  users.id = winning_coinflip_bets.user_id
               AND `coinflip_games`.`state` = ?)
       AS `max_coinflip_jackpot`  )

FROM   `users`
WHERE  `id` = ?
)

SELECT TOP 1 id FROM people WHERE name = 'Ann'

так работает?

UPDATE
    sales as s
SET s.plan_payment_date = (SELECT 
                                                       MAX(pay.payment_date) 
                                                   FROM 
                                                       payments pay
                                                   ,  payments_parts pp
                                                   WHERE pay.ID = pp.FK_payment
                                                          and s.ID = pp.FK_sale 
                                             )

Хотя сам бы за такое пальцы отрубил бы исполнителю )))

INSERT INTO tab1 (f1,f2,f3) SELECT v1,v2,v3 FROM tab2

В общем случае нельзя сказать однозначно.... в целом индексы предназначены для ускорения доступа к записям, в т.ч. при удалении и изменении. Но индекс, это отдельная структура на ведение которой СУБД тратит свои ресурсы. Например, при вставке данных в таблицу на которой "висит" 5 индексов, идет еще пять вставок в каждый из этих индексов. Причем вставить новую строку в индекс гораздо сложнее (с точки зрения ресурсов СУБД, возможно в зависимости от используемой СУБД) чем в таблицу, т.к. сначала необходимо найти место куда эту строку вставлять (сейчас говорю о наиболее распространенных b-tree индексах) и ссылки блоках индекса.
Более того, говорить о том, что индекс ВСЕГДА ускоряет доступ к записям - тоже неверно. Все зависит от вашего запроса и способа доступа к данным. Если данных для запроса достаточно в индексе, то СУБД выгребет данные вообще без доступа к таблице. Это во многих случаях (но не всегда :)) будет сильно быстрее чем извлечение данных непосредственно из таблицы. Если в запросе извлекается данных больше чем содержит индекс, то СУБД будет (если ее заставить) сначала обращаться к индексу для того что бы найти адрес строки в таблице, а затем полезет в таблицу и извлечет необходимые данные). Будет ли это быстрее чем просто искать по таблице? - во многом зависит от того сколько % записей должен вернуть запрос. Обычно рекомендация такова: если запрос должен вернуть больше 15-20% строк таблицы, то использование индексов нецелесообразно... Но даже тут есть 100500 тонкостей и особенностей.... В общем в этом вопросе мир тоже не делится на белое и черное... как то так...