Потому что md5($row['sha2'].'1') и md5($sha2).'1' разные вещи.

Хеш-функция от разных строк даст разные хеш-суммы (ну кроме коллизий, но мы же не их ищем :)). В твоем случае последний md5 считается от разных строк. Почему? Ответ выше :)

Замени $hash = md5(md5($whirlpool).md5($sha2).'1');
на $hash = md5(md5($whirlpool).md5($sha2.'1')); и будет равенство.

Второй скрипт создает сервер ØMQ на 5555 порту. Логично, что если этот скрипт умрет, то и сервера на 5555 не будет. Поэтому надо чтобы второй скрипт работал непрерывно.

Первый скрипт открывает соединение с сервером ØMQ (клиент) и отправляет сообщение. Надо ли ему дальше жить? Судя по коду нет - он единождый отправил и свою работу выполнил. А если не по коду - who knows.

Братюнь, ты для себя просто определи, что тебе важно.

Если ты часто таскаешь с собой, то тут надо крепко подумать об Air, бонусом будет чуть большая жизнь на батарейке

Если важна бекенд разработка, то возьми не ретину и сразу докупи RAM и SSD, на оставшиеся 20к, потому как с 4Гб и медленным диском удовольствие от работы то еще, тем более Java.

Если важна именно ретина, то сам понимаешь - бери. Но на 13" это сомнительное удовольствие, все же размер экранчика для глаз не очень комфортный. У меня была прошка обычная 13", работал в основном с внешним монитором, так как на экране ноута места не хватало.

А так да, ретина это офигенно, но на 15", мне очень нравится =)

Похоже, что при описании проблемы упущен важный момент, а как эти поля будут использоваться. Нужны ли будут данные из них всегда или только в определенных случаях?

Давай посмотрим плюсы и минусы решений. Ну как я их вижу.
Для варианта номер один.
Плюсы:
- со стороны PHP легко будет расширить AR
Минусы:
- unserialize медлено, есть конечно json и igbinary, но это все равно время
- если полей "будет становиться всё больше", то в MySQL сериализованые данные нужно будет хранить в TEXT/BINARY поле, если мы говорим о стандартных ENGINE MySQL, то при выборке такие поля в память не загружаются, а читаются с диска, ну ты понимаешь, что дисковые I/O операции дорогие (в случае с InnoDB там может быть лучше ситуация)
- если у нас случай, когда данные из "неизвестных" полей нам нужны редко, то при таком подходе, либо надо будет рисовать workaround в AR чтобы эти поля не тащить, либо будут данные постоянно пересылаться м/у БД и PHP, плюс в памяти PHP висеть
- если база разрастется и нужно будет вытащить "неизвестное" поле в поиск/фильтрацию, изменение схемы таблицы потребует времени, вытаскивание данных из сериализованного поля и заполнение нового поля - потребует времени, построение индекса по новому полю - потребует времени. Много данных - много времени, времени простоя сервиса.

Для варианта два.
Плюсы:
- если размер данных в полях лимитирован и залезает в тип VARCHAR, решаем проблему номер два первого способа
- масштабируемо
- внедрение поиска/фильтра по полю не повлечет переделывания структуры таблиц
Минусы:
- если данные нужны всегда, получится JOIN,если полей с данными будет много, то JOIN будет медленным. Если тип у полей будет TEXT... ну ты понял :)
- проблему один можно решить кешированием, но реализация на PHP в рамках AR уже станет не самой простой задачей
- да вообще в рамках AR Yii реализация такого подхода с lazy loading потребует нормального такого понимания, как AR в Yii устроен и где его надо менять, чтобы всем было хорошо

Правильного варианта, как ты понимаешь нет, нужно взвесить все "за" и "против", понять насколько имеет смысл делать "круто" сейчас и тратить время или можно залезть в technical debt, но быстро запуститься уже завтра.