Существует несколько таблиц: Заказ, События к заказу, Документы к заказу, Счет, Накладная и т.д. Они все как-то связаны.
Появилась идея, дать пользователю некий конструктор, чтобы он мог выбрать поля из интересующих его таблиц, например, выбирает из Заказа поля Номер, Дата, Описание и выбирает из таблицы Событий несколько событий: Оформлен, Поступил, Отправлен.
Получится вот такой отчёт
№ | Дата | Описание | Оформлен | Поступил | Отправлен
1 | 17.08 | Ок | 01.09 | 05.09 | 06.09
В данном случае мне на беке необходимо сделать запрос на таблицу Заказ и сделать один джоин на таблицу События.
Другой клиент может выбрать некоторые поля из таблицы Заказ и Документы, в таком случае, под его "отчёт" необходимо будет сделать джоин между таблицами Заказ и Документы. Третий захочет из трёх таблиц и нужны будут свои джоины
Чисто технически я могу сделать здоровенную вьюху, в которой переджоиню все таблицы-участники. Чтобы был один источник данных. Но мне не нравится такой вариант, так как просто джоин на таблицу документов занимает 3-5 секунд. И если поля по документам не будут использоваться в отчёте, соответственно лишнее время на получение данных. Ну и если учесть все джоины, то время увеличивается до 20-25 секунд на запрос, что нереально много.
Быть может это нормальный вариант, если сделать какую-то предрассчётную вьюху, либо, даже, целую таблицу выделить под это дело с уже готовыми данными (пускай дублируются), подскажите, есть что-то такое в MS SQL сервере?
Если пойти дальше, можно даже задействовать сервис аналитики (BI которые), например, заливать все данные в табулярную модель, тогда итоговые запросы будут просто летать. Тут так же появится дополнительная перекачка данных, это лаг и неясная нагрузка, я с такими вещами только с краю стоял, когда кто-то делал.
На ум приходит еще такой вариант, я беру просто StringBuilder и на if-ах на бекенде строю запрос для sql.
Типа, если выбрано хоть одно поле из документов, то добавляю джоин на документы. Но писать sql запрос в стрингу, тоже такой себе вариант.
ayazer, давным-давно перешёл на linq, понял прелесть типизации. Тяжело сопровождать, могут быть опечатки всякие, кто-то внёс правочку, у каких-то клиентов что-то отвалилось ) в целом, можно, конечно
Есть старая система, в которой под каждый такой отчёт для разных клиентов делают хранимку. Многие такие отчёты реально различаются на пару полей. Отчётами пользуются. Очень много времени на сопровождение, как вы понимаете.
Хотят сделать новую систему и исправить такую ситуацию.
Я не говорил, что сам клиент будет тыкать какие-то галки, но эту работу смело можно переложить с разработчиков на клиентских менеджеров.
Единственный момент, если я сделаю здоровенную общую вьюху, она будет работать медленнее (мне кажется сильно медленнее, но я не проверял), чем запрос под конкретный отчёт. То есть, появится такой же отчёт, который был, но будет загружаться полминуты, так я не хочу
Виктор П., это называется аналитика и репортинг. В этом мире все работает на SQL и Jupiter notebook'ах. кроме того разработчикам написать SQL запрос быстрее и надежнее чем какой либо конструктор. И отлаживать так проще. Кто такие клиентские менеджеры я не знаю но предполагаю что это вообще не их работа
Иван Шумов, так я, вроде, сразу и написал, что не умею ) умел бы, не спрашивал бы ))
Пока это всё на уровне идеи, поэтому еще ничего не проверял. Смотрю, как подобные задачи решаются, какие методы вообще существуют. то-то не умеет в колоночные базы данных - ну я не умею, Иван, к чему оскорбления и к чему эти пустые обсуждения? занимается предполагаемой оптимизацией - кто занимается? Я лишь сказал, что если в отчете шесть колонок из двух таблиц, то конкретный запрос для этого отчёта будет содержать 6 колонок и один джоин и это будет быстрее, чем использовать под данный отчёт какой-то общий запрос, который будет содержать 250 полей и 13 джоинов, это и ежу понятно.
В своём вопросе я уже предложил три варианта, надеюсь, что мне подскажут какие-то другие варианты. Или хотя бы скажут, чувак, я делал вьюху, да, пришлось немного пожертвовать производительностью, ради удобства, но это стоило того, потому что вот так. И мы сделали еще вот это и всё вообще супер стало.
А вот эти обсуждения "хаха, кто-то не умеет в колоночные бд" - к чему? стыдно должно быть
Виктор П., никакого хаха и м не не стыдно. Просто указал на факт. А вообще, повторюсь, идея бесполезная. Любое решение должно закрывать потребность, а не делать ту же работу, но иначе. Визуальный построитель запросов может закрывать только одну проблему - отсутствие квалификации пользователя. Учитывая что одни из основных пользователей - программисты то это изначально глупо и бесполезно
Иван Шумов, Дискутировать можно бесконечно. Не очень понимаю, зачем этим заниматься, но ладно )
Вы говорите отличную фразу: "Любое решение должно закрывать потребность, а не делать ту же работу, но иначе." Тут же приводите аргумент, какую проблему закрывает данный инструмент: "Визуальный построитель запросов может закрывать только одну проблему - отсутствие квалификации пользователя."
Отлично, вы сами себе доказали, что идея не бесполезна, а решает целую проблему!
И даже указали на целевую аудиторию, этим инструментом будут пользоваться не программисты, а я добавлю, системные аналитики и даже клиентские менеджеры, если им еще инструкцию написать.
Замечательно
Иван Шумов, Иван, я не пойму, что вы пытаетесь тут обсудить. "Системные аналитики" так же размазанное определение, как и клиентские менеджеры, они в разных компаниях могут заниматься совершенно различными, даже противоположными вещами. не подразумевает серьезную умственную деятельность для работы с системами анализа - окей, ранее было сказано, что для таких людей и пишется этот инструмент.
Вы в который раз твердите, что проще под каждый новый отчёт делать свою хранимку, апи, плюс веб часть. (И потом тратить силы на сопровождение). Я говорю, что проще сделать универсальный конструктор под все такие отчёты, тем более, что им смогут пользоваться простые смертные, кто не знает sql. Я выслушал ваше мнение, принял его, тем не менее, оно не относится к вопросу, заданному изначально, хватит это обсуждать.
