Виктор

Сколько места сэкомомиться

- В json идет доп. расход места на хранение имен ключей, структуру и синтаксис, (числовые) значения в строковом представлении.
+ Экономия может быть за счет того что нет резерва для строк фиксированного размера.
+ Так же экономия может быть за счет редких полей, которые нужны не в каждой строке таблицы.
Так же json можно хорошо сжать, но поддерживает ли это psql...
Результат зависит от типа данных (и метода хранения).

2.Производительность

В теории должна быть ниже т.к. кроме выделения строки в таблице, нужно выделять место под этот json + его валидация.

3.Какие еще плюсы и минусы

+ Можно хранить сложные структуры данных
+ Позволяет делать прозрачные миграции (развитие проекта без миграций)
- Требует больше места по сравнению с простыми колонками (числа/даты)

Метод не использует данных объекта, так что ничего не мешает ему быть вызванным статически. Если бы внутри было обращение к полю через $this, то выскочила бы ошибка.
И да - это PHP...

man 7 namespaces

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

без команды, дизайнеров и прочих посредников .

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

Ну альтернатива - соберите себе ту самую кросфункциональную команду, дизайнера, QA, может еще пару девелоперов и радуйтесь. А в одиночку не выжить.

Учите английский.

А если серьезно, то ответом на вопрос "Что мне нужно знать, чтобы заменить целую команду разработчиков из разных сфер" может быть только "Всё".

Либо делайте как все - находите заказы только по своему профилю.

#! /bin/sed -nf

1{p;h;}
2~1{H;x;s/\n.//;p;}
x
s/^\(.\).*$/\1/
h

А теперь попробуй понять, как это работает.

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

Попробуйте dokuwiki.ru с плагином tag

Большие яйца.

Если выбор стоит между CMS и фреймворком, есть довольно простой алгоритм. Если возможности CMS решают 100% задач и быстрого дальнейшего развития не ожидается - надо брать CMS. Если же хотя бы 5% функционала придётся дописывать, лучше взять фреймворк и сделать всё под себя.

Как показывает практика, эти 5% допилок окажутся такой головной болью в будущем, что сделать 100% функционала на фреймворке будет дешевле и быстрее.

Иван
Примерные затраты на разработку до инвистиций - цена/срок
butik.ru - 8 000 000 / 6 месяцев
lamoda.ru - 14 000 000 / 4 месяца
wb.ru - 18 000 000 / 8 месяцев

PostgresQL.