Илья, можно имитировать синхронную репликацию с помощью WAIT https://redis.io/topics/replication
а так же можно включить fsync AOF для каждого запроса.
Оба решения многократно просадят скорость записи, но обеспечивают персистентность на уровне релиционных СУБД.
За видос спасибо)
Илья, да не подставишь, но их можно вывести рядом в селекте, а значит что можно создать представление или реальную таблицу с нужным видом. Хотя вариант со стрелками, данном случае, выглядит самым простым.
Так данные не структурированные же.
Да и типы определить динамически вряд ли получится.
Для джоина нужно знать конкретное имя и тип поля, и желательно иметь индекс на нём.
В общем в любом случае приходим к ручному разбору. С помощью функций jsonb_to_recordset/jsonb_to_record/jsonb_populate_recordset/jsonb_populate_record это делать удобнее чем с помощью стрелок.
Для удобного просмотра можно создать VIEW.
Ещё полезными бывают генерируемые колонки.
Хороший ответ, от себя добавлю что можно вместо одного или обоих индексов, создать 4-х колоночный, желательно располагать колонки в порядке уменьшения селективности, или ориентируясь на другие запросы которые могут использовать этот индекс.
То есть, поскольку у вас вряд ли много разных language_id, и word_id должно быть больше. Вот word_id лучше поставить первым в таком индексе.
NLexeych, новички в айти всегда входят с ярым фанатизмом. Это же так интересно, заставлять машину делать то, что ты от неё хочешь.
А сколько мест работы у вас было за эти самые 3 года? И какого рода эта разработка? Продуктовая, проектная? Сама компания - IT, или нужен просто программист в штате, а основная сфера деятельности другая?
pcdesign, тогда отчасти соглашусь. Вообще есть теория что сейчас все жалуются на усталость, не потому что много работают, а потому что мозг перегружается информацией из кучи источников.
Если жёстко ограничивать поток информации работая программистом, легко деградировать профессионально, и обречь себя тем самым, на самую скучную и не интересную работу, в этой сфере.
Просто не вывезете конкуренцию с теми кто этим живёт постоянно.
Нужна ли вам эта конкуренция - другой вопрос.
NLexeych, если после работы не хочется думать о работе, скорее всего это не ваше. Ничего страшного, бывает, найдите сферу к которой будет больше интереса, или хотя бы требующую меньше интереса.
AlexBergal, https://postgrespro.ru/docs/postgrespro/9.6/indexe...
я про это.
Делаем индекс с условием where active = true и он во-первых меньше, во-вторых точно применится, если такое же условие будет в запросе, в-третьих он будет пересчитываться только при изменениях в строках попадающих под это условие.
Так же можно создать поле - массив фильмов, и с помощью этого расширения https://www.postgresql.org/docs/current/intarray.html вычислять пересечения массивов у тех, у кого в принципе больше 7 фильмов, и смотреть на длину этих пересечений
1. Сейчас подумал что это идеальная задача для СУБД на графах. Правда что будет.с временем ответа сложно сказать.
2. В общем нужен триггер на таблицу связей, который будет записывать актуальное количество фильмов для каждого юзера в специальное поле в таблице users,
и индекс CREATE INDEX idx_boost_second on users (city_id, cnt_films) where active = true;
React вам тут погоды не делает, а но PHP поддерживает сокеты только с костылями, и у MySQL нет функционала подписки/уведомлений. Так что работы будет больше, чем с более подходящими инструментами. Плюс надо будет обязательно измерить расход памяти на сокеты в PHP. Возможно для 1000 одновременных подключений понадобится более дорогой сервер, чем с другими языками
Vadym Masiuk, ну тогда берите любую реализацию сокетов для PHP. Во всяких асинхронных форках есть. Есть ещё Swoole, Ratchet. Сам не пробовал, но отзывы слышал исключительно плохие.
Андрей Решетов, не за что) У хасуры, кстати, много хороших примеров на их ютуб канале) Там правда опять же на английском и в основном с индийским акцентом, но всё же)
И я на ней, некоторые вещи, которые делались достаточно сложно на фреймворках с ОРМ, повторил играючи)
Андрей Решетов, можете ещё посмотреть в сторону headless cms, или вещей типа hasura.io в качестве бэкенда. Но тогда придётся осваивать инструменты серверного рендеринга для фронтенд-фреймворков. Если конечно хотите чтобы сайт нормально индексировался всеми поисковиками.
Можно будет не вникать в бэкенд, и прокачать фронтенд.
Или действительно взять CMS. На Node.js они, кстати, тоже существуют, но популярных нет.
Андрей Решетов, хм. Ну если вы именно понимаете программирование, и хорошо с английским, то посмотрев годный видеокурс, и вооружившись документацией, вы в любом случае за пару недель разберётесь в новой технологии.
Чтобы было проще, имеет смысл остановиться на Node.js. https://adminbro.com/ Тут есть готовая админка и пример приложения с использованием express
Мне когда было лет 7, мама рассказывала, что у них на заводе, опытные токари, большую часть рабочего дня курят, либо играют в домино. Потому что план они выполнить могут часа за 2,5-3. Если они начнут перевыполнять план, то им в этом месяце дадут премию, а следующем просто поднимут план. Навсегда.
И тогда даже ребёнку стало очевидно что нужна либо, сдельная оплата, либо премии которые честно выплачивают за переработки каждый месяц.
У вас похожая ситуация. При такой финансовой мотивации, у разработчиков нет мотива не то что вести трекер, но и вести его честно.
Думаю самый адекватный подход, это оклад плюс премия KPI. Величина премии зависит от нескольких факторов, прежде всего выполнения плана. План формируется на спринт, заранее, из оценок команды, или самого разраба.
Остальные, небольшие части премии, это ведение трекера и возможно какие-то задачи типа технических собеседований, проведения код-ревью, обучения джунов, оценок от непосредственного руководителя (если такие есть).
Сразу появляется денежный мотив вести трекер, и пропадает возможность лишиться денег если в трекере мало часов на задачу проставлено.
Как-то так.
а так же можно включить fsync AOF для каждого запроса.
Оба решения многократно просадят скорость записи, но обеспечивают персистентность на уровне релиционных СУБД.
За видос спасибо)