зачем хранить ограниченное количество?

Ну я тебе добавлю бесконечное кол-во полей и сервак ляжет.

Создам огромное кол-во анкет с огромным кол-вом полей.

Ну я тебе добавлю бесконечное кол-во полей и сервак ляжет.

Это все валидациями решается

Но полей может быть довольно много на самом деле.

Это все валидациями решается

Мы опять уходим далеко от темы, я про решение с JSON.

Конкретно.

С другими решениями - другие проблемы.

Плюс с json появляются проблемы типа "удалил поле, что делать со старыми полями?"

Да хрен с ними, они уникальны для одной анкеты.

Ну смотри

у тебя есть список полей с типом

для анкеты. И кто то заполнил анкету

теперь владелец анкеты удалил поле. Как отобразить старое поле?

Где отображать?

В ответе? Ответ сохранит старое поле, оно же в JSON будет.

На вебморде

результаты надо же как то агрегировать или отображать.

Анкета - набор полей в JSON.

Ответы - ответы в JSON.

Связи между ними никакой вообще.

Теперь ты на вебморде один из результатов заполнения выводишь

Связи между ними никакой вообще.

лол что

А тип поля ты не знаешь, что делать?

избыточность?

А тип поля ты не знаешь, что делать?

Почему не знаю-то?

"key" => "value"

Потому что это поле было удалено

Название поля и ответ.

поле может хранить дату например

Потому что это поле было удалено

Из всех ответов? Зачем?

Оно было удалено из анкеты, а в json ответе осталось

Как отобразить это поле в вебморде теперь?

Оно было удалено из анкеты, а в json ответе осталось

Так и отображать его из ответов. Или не отображать, если так нужно.

Оно было удалено из анкеты, а в json ответе осталось

ты про массив думаешь наверняка, а он про объект

Как отобразить это поле в вебморде теперь?

В чём проблема отобразить ответ на поле "key"?

но с объектом непонятно что будет ключами

Я, право, не понимаю, о чём сейчас речь.

ты про массив думаешь наверняка, а он про объект

Есть анкета с полями. Кто то заполнил такую анкету, в дальнейшем называем "Результат". Теперь из структуры самой анкеты снесли поле

Есть анкета с полями. Кто то заполнил такую анкету, в дальнейшем называем "Результат". Теперь из структуры самой анкеты снесли поле

А в ответе будет "Результат".

Его и показываем. Если не нужно, то не показываем.

Теперь мы не знаем как вывести garage_sell_date

потому что мы не знаем его тип.

Есть анкета с полями. Кто то заполнил такую анкету, в дальнейшем называем "Результат". Теперь из структуры самой анкеты снесли поле

ну если объект — пофиг, не выводим просто

Мы, видимо, про разные вещи.

ибо не находим в вопросах

если массив — то будут проблемы

ибо не находим в вопросах

Да. Можно сверять структуру с анкетой а можно не сверять.

В зависимости от задачи, опять же.

Просто с реляционным подходом это проще решить

Впрочем все как правило опирается в задачи бизнес логики, и тогда уже надо выбирать вариант

Где то json очень катит.

условно говоря, anketa.each { |name, type| display answer[name] } и если в answer есть что-то, чего нет в анкете — просто не отобразится

ну да, я почему то об этом не подумал.

Но получается что мы в базе храним поле которого в анкете уже нет. А вот ответить нужно ли хранить данные по удаленному полю или нет может только бизнес.

ну да, я почему то об этом не подумал.

а если автор анкеты (ошибся) снова вернёт это поле — у старых ответов не затрётся

Закроем тему на основании того что у нас недостаточно данных какое решение лучше именно для того кто спрашивал

Но получается что мы в базе храним поле которого в анкете уже нет. А вот ответить нужно ли хранить данные по удаленному полю или нет может только бизнес.

ну да. тут либо плюшка с возвращением вопроса, либо чистка запросом, особенно страшным, мне кажется, для json

Закроем тему на основании того что у нас недостаточно данных какое решение лучше именно для того кто спрашивал

yep

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

но для документов jsonb оочень катит.

вспоминая рекомендации «профессионалов масштабирования» много лет назад, нужно на каждую анкету таблицу в бд создавать!

Это энтерпрайз

у них может быть по тысяче табличек в базе

всем привет, написал метод поиска всех записе по словам из строки def self.search_by_title(title) words = title.to_s.downcase.strip.split.uniq words.map! { |word| "title LIKE '%#{word}%'" } sql = words.join(' OR ') self.where(sql) end но если в строке есть ', то получается беда и пишет Recipe Load (0.6ms) SELECT "recipes".* FROM "recipes" WHERE (title LIKE '%test's%') ORDER BY "recipes"."id" DESC LIMIT 1 ActiveRecord::StatementInvalid: PG::SyntaxError: ERROR: syntax error at or near "s" LINE 1: ...ecipes".* FROM "recipes" WHERE (title LIKE '%test's%') ORDE... как это можно решить?)

ERROR: S client not available

потому что надо использовать prepared statements

вместо интерполяции строки

У тебя вообще логика не правильно построена, юзай AR для создания запроса а не сам его рисуй

тогда и prepared statements Будут

http://stackoverflow.com/a/19105790 первый же результат поиска не ленитесь

Да и для поиска есть инструмент получше.

ок, спасибо всем, ща буду разбираться)

Да и для поиска есть инструмент получше.

какой?

для постгресса у нас что то для поиска юзалось

правда потом нам это не понравилось и мы на эластику перешли

но может подойти.

какой?

Вроде этот https://github.com/Casecommons/pg_search

всем привет, написал метод поиска всех записе по словам из строки def self.search_by_title(title) words = title.to_s.downcase.strip.split.uniq words.map! { |word| "title LIKE '%#{word}%'" } sql = words.join(' OR ') self.where(sql) end но если в строке есть ', то получается беда и пишет Recipe Load (0.6ms) SELECT "recipes".* FROM "recipes" WHERE (title LIKE '%test's%') ORDER BY "recipes"."id" DESC LIMIT 1 ActiveRecord::StatementInvalid: PG::SyntaxError: ERROR: syntax error at or near "s" LINE 1: ...ecipes".* FROM "recipes" WHERE (title LIKE '%test's%') ORDE... как это можно решить?)

у тебя тут потенциально возможна sql инъекция, лучше так: recipes.where('title ILIKE :query', query: title)

https://www.sitepoint.com/n-1-when-more-queries-is-a-good-thing/ ребят, я правильно понимаю, что (условно) 10 запросов из первого скриншота выполняются суммарно быстрее, чем один запрос из второго скриншота?

по-моему, суть в том, что 10 запросов с первого скриншота выполняются один раз и кэшируются, а один запрос со второго выполняется каждый раз

по-моему, суть в том, что 10 запросов с первого скриншота выполняются один раз и кэшируются, а один запрос со второго выполняется каждый раз

кэшируются где, чем и как?

чем угодно

бд, в редис

ну вот мне интересно чем: на уровне БД, или гема, или чего-то ещё

я в sequel с postgresql видел подобную ситуацию и призадумался, нужны ли мне джоины, или обычного игера достаточно

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

ну и есть identity_cache, который кэширует запросы к БД

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

какая ещё матрёшка? это вообще нигде не упоминалось же

но мне кажется лучше не ебаться и инклудить

ну и есть identity_cache, который кэширует запросы к БД

где, в activerecord?

ну статья хуевая значит

да

в рэдисе

первый скриншот: да они кэшируются и суммарное время выполнения 11 ms, второй 52,2

или мемкеше

омг, ок, ты меня не слышишь