ponaehal

Хех. В свое время использовал следующий лайфхак:

SELECT ..... WHERE ..... AND publisher_type= 0
UNION ALL -- важно не UNION, а UNION ALL (разницу погуглите)
SELECT ..... WHERE ..... AND publisher_type <> 0

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

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

Появилась мысль разработать что-то подобное для собственных нужд.

Убейте эту мысль в зародыше. Изобретать велосипед - наш национальный вид спорта.

Возможно я не прав, но складывается такое ощущение, что Вы слегка опережаете паровоз. Т.е. реальная потребность в CRM еще не сформировалась. Именно по этому и

ничего не зашло

.
Я бы предложил усилить продажи и разработку, а к вопросу CRM вернуться именно тогда, когда это станет проблемой. Вы сами почувствуете этот момент, когда два менеджера по продажам начнут звонить одному и тому же клиенту с целью продать услуги или когда к вам обратится клиент и с просит: "а помните вы мне делали?", а Вы с ужасом поймете что нифига не помните, и вообще, тех разработчиков уже нет, договор не найдете.
И тогда у Вас родятся требования к системе:
- KYC;
- учет договорной базы;
- учет и планирование коммуникаций с клиентом;
На данном же этапе развития вашей студии "проблема CRM" выглядит слегка притянутой за уши. М.б. Вам действительно нужна трекинговая система типа jira или redmine (до CRM и систем управления проектами они в общем случае не дотягивают).

По полю id группировать в общем то бесполезно, т.к. для каждой записи оно уникально. Если без него, то так:
SELECT departmentId, type, MAX(revision) from table_name GROUP BY departmentId, type

По описанию похожа на "задачу коммивояжера". Соответственно, гуглите "решение задачи коммивояжера"

На мой личный взгляд:
1. С людьми работать (управление проектами или управление подразделением) интереснее, но намного сложнее чем писать код. Люди не прощают ошибок...
2. Придется отпустить компетенции по разработке и приобрести новые. Это нелегко и поначалу пытаешься "усидеть на двух стульях", а это только вредит. Готовы?
3. З/п вторична. Действительно, хороший разработчик может получать больше многих РП. ИМХО надо выбирать то, к чему лежит душа, только в этом случае будете гармонично развиваться.
4. Не стоит думать, что РП - это только проведение совещаний и верстка плана. На некоторых этапах проекта (инициация, завершения) РП работает больше остальных членов команды.
5. Культура в компании. Если система управления в компании не зрелая, то стоит трижды подумать прежде чем брать на себя ответственность за результат, который от тебя может и не зависеть. Например: Вас назначили РП, а реальных ресурсов не дают (людей постоянно отвлекают на иные работы их непосредственные функциональные руководители). Работа сведется к "борьбе с ветряными мельницами" (с непонятным исходом). В таких условиях лучше отвечать за себя и свой труд (например, быть девелопером).
6. У девелоперов сейчас есть поразительная возможность работать на удаленке (воображение рисует какой-нибудь тайский пляж с гомаком и ноутбуком). У РП таких возможностей намного меньше.
7. У РП действительно больше возможностей чем у девелопера, для восхождения по карьерной лестнице. Хорошо это или плохо решать Вам. Чем выше взойдете, тем сложнее найти работу:)

ЗЫ Всегда при принятии таких важных решений пытаюсь исходить из принципа "лучше сделать и жалеть, чем жалеть что не сделал". )) Ни на что не намекаю, ни к чему не призываю))

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

Процедуры сборки, развертывания, тестирования автоматизировали?
В моем понимании, если Вы утром следующего дня прийдете на работу и увидите развернутую на тестовом сервере версию с отчетом о прохождении тестов, то время с dev до prod сокращается до 2 дней (утром стабилизируете и после обеда получаете стабильный релиз).
Проверено на практике. Собирали мы не раз в две недели а каждую ночь. Базовые проверки проходили ночью, а функционал аналитики проверяли только при подготовке обновления у заказчика.

Важно: на prod накатывать не результирующую сборку, а все сборки ровно в том последовательности в которой накатывали на stage (сначала нестабильный релиз, потом фиксы до стабильного). Это нужно что бы исключить ошибки при повторной сборке.

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

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

1. Необходимо осознать что придумывать колесо - пустая трата времени. Лучше взять одно из тех что продается в магазине и научиться им пользоваться (возможно после этого оно Вам понравится).
2. Вы не напишите свой майндмап, хотя бы просто потому, что такие продукты не создаются в одиночку. Все что может получиться у одного, даже очень опытного, разработчика - некий каркас или полуфабрикат, который по функциональности не сможет конкурировать ни с одним из существующих на рынке продуктов. Потребуется много-много человеко-часов до того момента когда из "этого" получится продукт.
3. Если интересно программирование, то начинать в любом случае придется с решения задачи "hello world!".
4. Обучаться лучше всего решая конкретную прикладную ПРОСТУЮ задачку, которую можно сделать в одиночку в обозримом будущем.

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

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` = ?
)

В разработке это потолок. Дальше только в менеджеры (не pm, а руководитель подразделения). или менять сферу деятельности. или менять приоритеты в жизни (работа не главное).
Важно понимать, что работу pm вы найдете всегда вплоть до пенсии, а если пойдете в начальники, то после какого то уровня работу будет искать сложнее (позиций больших начальников мало), особенно в вашем городе.
Советовать что-либо бессмысленно, ИМХО

европа PRINCE2, пендостан PMP, и везде требуется CS :)

мутация?)

Примерно(!) так:

SELECT  * FROM 
(
select 
  ID
, LEAD(id) OVER (ORDER BY user_id)  lead_id
from your_table
) tab
WHERE tab.id= tab.lead_id

Позвольте уточняющий вопрос:
1. Что именно Вас не устраивает в менеджменте на Вашем текущем месте работы?
2. Почему Вы свою компанию собираетесь "пилить свою компанию с блекджеком и аджайлом"?

Посмотрите Nintex/Doctrix, вдруг именно это ищите

ИМХО, общий подход (вне зависимости от используемой библиотеки):
Почти любая библиотека может заполнять одну ячейку, а может диапазон.
Нужно сформировать диапазон (диапазоны) в БД, а потом залить его в эксель одной (несколькими) операцией.
По опыту, на больших файлах это даст прирост производительности на несколько порядков