Константин Нагибович

в большинстве случаев нет никакого смысла делать мобильное приложение.
Сайт будет делать то же самое причем независимо от мобильного девайта.
Да и пользователям проще открыть сайт чем ставить на телефон неведомую програму

Ну если клиент хочет дешевле то оплачивает разработку ТЗ, если дороже то можно вот так то эпо наитию работать с оплатой каждого чиха

Навык общения с клиентами и перевода с "клиентского" языка на технический — это одно из конкурентных преимуществ во фрилансе. Так же как и навыки презентации и продажи своих услуг.

Либо нужно их развивать, либо работать в команде с тем, кто ими обладает. И тот и другой путь вполне эффективен.

Вам вставить картинку из кружков

Или напомнить историю нетскецпа

За хороший Красивый код не платят

Бывают правда исключения но это отдельная история

в основном так и есть.
бизнесу насрать на наши модели и архитектуру, ему надо деньги делать и ещё вчера.

если вылизывать архитектуру со старта - никогда не взлетишь. а когда и если взлетишь, поляна будет уже засеяна другими, которые срать–плевали на красоту кода.

это итеративный процесс: сначала столбим делянку как-нибудь (MVP), затем так и живём или приводим её в порядок.

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

P. S. На всякий случай отвечу отдельно - ответ на вопрос из заголовка: "Да".

За время пандемии все привыкли к зумам, конференциям и всему такому. Возможно, поэтому созвоны стали восприниматься как что-то обыденное.

Я бы посоветовал следующий подход: до заключения контракта и при fixed-price контрактах созвоны стараться проводить быстро и строго по делу. А вот при hourly контрактах сразу обговаривать, что любые обсуждения - это тоже часть работы, соответственно не выключать таймер во время созвона, и тогда уже болтать столько, сколько хочет заказчик.

Студент за небольшую сумму.

Не хочется ругаться, но вопрос очень бессвязный и в нем перемешаны реальные проблемы с нелепыми фантазиями.

И проблема тут не в незнании как работать с большими базами данных, а в неумении работать с БД в целом.

Про идею "всем индекс не поставишь" надо сразу забыть. Там где индекс нужен, он должен стоять без вариантов. Другое дело что тупо натыкать индексов по всем полям, по которым идёт поиск - это тоже глупость. Индекс в запросе может использоваться только один, и индексы по второму-третьему полю уже будут бесполезны. Надо анализировать запросы и, возможно, делать составные индексы.

Детсадовский запрос вида like '%...%' - это отдельный ужас. Надо смотреть на полнотекстовый поиск. А лучше вообще его избегать. На крайний случай использовать внешние поисковые сервисы типа эластика. И только не говори что этот лайк у тебя идёт по полю типа джейсон или "через запятую"

Но самый конечно кошмар - это select distinct для фильтров. То есть неумение проектировать бд на самом базовом уровне, непонимание самых начальных принципов реляционных бд, нормализации. Вот с этих принципов и надо начать. В потом уже хвататься за большие объемы. Очевидно, что поля по которым ты собрался делать "distinct" - это должны быть отдельные таблицы, от которых в основной таблице будет просто id. поле размером в 4 байта.

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

В общем, куда лучше бы смотрелись здесь не абстрактные рассуждения про большие объёмы, а конкретный запрос, который "отваливается". С обязательным результатом EXPLAIN

А ответ на абстрактный вопрос "как работать с большими объемами" очень простой: точно так же, как с небольшими. Реляционные бд изначально проектировались под большие размеры. То есть надо просто уметь работать с бд. Читать про реляционную модель, нормализацию, индексы, оптимизацию запросов.

Конкретно для грида надо смотреть в сторону Эластика/Сфинкса. В смысле чтобы не только для полнотекстового поиска, а чтобы все фильтры, которые есть выборке, были забиты в поисковый индекс. И все выборки - через поисковый сервис, а не через прямой запрос к базе