ReSQL.ru
     
powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Программирование [игнор отключен] [закрыт для гостей] / Произвольная таблица
10 сообщений из 10, страница 1 из 1
Произвольная таблица
    #38907645
Bercof
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Bercof
Гость
Добрый день.

Имеется:
Некоторая система, по функционалу достаточно похожа на Bug Tracker, т.е. прочесс работы с ней таков:
1. Клиент заполняет форму обращения. И видит все свои обращения.
2. Супервизор видит все обращения и распределяет их по специалистам.
3. Специалист видит назначенные ему обращения и вносит принятое решение.

Работает это все как сайт на ASP.Net + MS SQL

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

Наше предполагаемое решение:
1. БД: реализовать 3 таблицы:
а) Обращения - основные не изменные поля (IdОбращения, дата, ...)
б) Типы параметров - (IdПараметра, Описание)
в) Параметры обращений - (Id, IdОбращения, IdПараметра, Значение) с внешнимим ключами на предыдущие таблицы
2. Реализовать настройку [Пользователь - Список Параметров]
3. Составлять динамический запрос: в зависимости от пользователя получать список его параметров.

Основная проблема: работать быстро это точно не будет. Динамический запрос будет каждый раз разный, соответственно SQL сервер не сможет корректно использовать статистику для оптимизации.

Вопрос:
Можно ли это реализовать как-то более оптимально?
Ограничение одно: система должна остаться на ASP.Net. БД - не принципиально.

Прошу сообщество помочь принять более правильное и оптимальное решение.

Заранее благодарю всех откликнувшихся.
...
Рейтинг: 0 / 0
17.03.2015, 22:54
| Ответить | Цитировать | Написать  
Произвольная таблица
    #38907720
Фотография SashaMercury
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SashaMercury
Участник
Bercof,
а справочников в базе не будет ? Три таблицы, и всё ?)

Как происходит авторизация ? Будет ли фиксироваться как отработали супервизоры ? Например, увидели они обращение, отработали ли они его сразу ?

Структуру БД в данном конкретном случае вполне возможно(а самое главное нужно) сделать жёсткой. Не вижу у вас каких-то проблем. Не так много возможных атрибутов которые вдруг могут понадобиться.
...
Рейтинг: 0 / 0
18.03.2015, 02:03
| Ответить | Цитировать | Написать  
Произвольная таблица
    #38907756
White Owl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
White Owl
Участник
BercofДобрый день.

Имеется:
Некоторая система, по функционалу достаточно похожа на Bug Tracker, т.е. прочесс работы с ней таков:
Первый вопрос: почему не взять одну из существующих систем? Зачем писать свою новую?

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

BercofОсновная проблема: работать быстро это точно не будет. Динамический запрос будет каждый раз разный, соответственно SQL сервер не сможет корректно использовать статистику для оптимизации.Глупости. Запросы всегда каждый раз разные. Это одна из реалий жизни и все СУБД прекрасно умеют с этим жить. Их для этого и создают.

BercofВопрос:
Можно ли это реализовать как-то более оптимально?
Ограничение одно: система должна остаться на ASP.Net. БД - не принципиально.1) Взять большую дубинку (финансовую, юридическую или деревянную) и побить пользователя чтобы он не лез куда не нужно.
2) Нанять профессионалов.
Все остальные решения может даже будут выглядеть привлекательно вот здесь и сейчас, но выльются вам в большую копеечку позже. Хотите сделать правильно и оптимально - не жмотьтесь на зарплате.
...
Рейтинг: 0 / 0
18.03.2015, 04:52
| Ответить | Цитировать | Написать  
Произвольная таблица
    #38907880
Фотография Akina
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Akina
Участник
В таблице Типы параметров надо, наверное, ещё добавить поле - Идентификатор пользователя-создателя. Иначе юзер будет видеть для своих записей не только свои дополнительные атрибуты, но и добавленные, например, админом, что не есть правильно...
...
Рейтинг: 0 / 0
18.03.2015, 09:45
| Ответить | Цитировать | Написать  
Произвольная таблица
    #38907944
Фотография Изопропил
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Изопропил
Участник
BercofДинамический запрос будет каждый раз разный, соответственно SQL сервер не сможет корректно использовать статистику для оптимизации
это называется "преждевременная оптимизация"

какая нагрузка планируется?
...
Рейтинг: 0 / 0
18.03.2015, 10:29
| Ответить | Цитировать | Написать  
Произвольная таблица
    #38909772
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
BercofНаше предполагаемое решение:
1. БД: реализовать 3 таблицы:
а) Обращения - основные не изменные поля (IdОбращения, дата, ...)
б) Типы параметров - (IdПараметра, Описание)
в) Параметры обращений - (Id, IdОбращения, IdПараметра, Значение) с внешнимим ключами на предыдущие таблицы
2. Реализовать настройку [Пользователь - Список Параметров]
3. Составлять динамический запрос: в зависимости от пользователя получать список его параметров.

Основная проблема: работать быстро это точно не будет. Динамический запрос будет каждый раз разный, соответственно SQL сервер не сможет корректно использовать статистику для оптимизации.

Вопрос:
Можно ли это реализовать как-то более оптимально?
Ограничение одно: система должна остаться на ASP.Net. БД - не принципиально.

Прошу сообщество помочь принять более правильное и оптимальное решение.

Заранее благодарю всех откликнувшихся.

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

Другое. В трендах современного времени можно предложить рассмотреть NoSQL системы.
Они хороши когда нужно очень быстро извлекать репорт. Удобно для документов.
Деревьев. И де-нормализованных данных. И данных со слабой связностью. И чем реже
будут данные изменятся - тем ближе система тяготеет (по одному dimension) к NoSQL.

Еще одно. Твой тезис

авторОсновная проблема: работать быстро это точно не будет.

Откуда такой пессимизм? Еще нет никаких метрик. Неизвестно даже количество строк. А
ты уже спешишь с месседжем о "полном провале".
...
Рейтинг: 0 / 0
19.03.2015, 13:25
| Ответить | Цитировать | Написать  
Произвольная таблица
    #38912010
Bercof
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Bercof
Гость
Добрый день.

Благодарю всех откликнувшихся! Извиняюсь: не было возможности ответить.

White OwlПервый вопрос: почему не взять одну из существующих систем? Зачем писать свою новую?
Потому что «а есть такой же, только без крыльев?» После просмотра нескольких вариантов бизнес сказал «мы хотим не много, делаем свое», при этом не особо вникая в детали... Распланировали, сделали – пару месяцев тишины…

White Owlкак этот функционал реализован внутри - дело разработчиков и пользователя не касающееся
А пользователи туда и не лезут. Вопрос возник по нашей недостаточной компетенции. Сделать то мы можем как описано, только вот:

maytonавторОсновная проблема: работать быстро это точно не будет.
Откуда такой пессимизм? Еще нет никаких метрик.
Пессимизм всплыл из-под «динамических запросов». Объемы не так важны. Скорее тут могут быть проблемы с динамическими запросами в MS SQL.
Была такая ситуация: был отчет (внешняя система, менять можем только список параметром и текст SQL запроса, реализовано для удобства доработок в хранимой процедуре), который формировался по многим таблицам и работал относительно шустро (в среднем 5-10 секунд).
Код: sql
1.
2.
3.
4.
5.
6.
7.
select
	Table.Field1, ...
from
	Table
	inner join ...
group by
	Table.Field1


Далее наши пользователи захотели переключатель «выводить и группировать по полю1 или полю2». Мы добавили соответствующий параметр на вход хранимой процедуры и сделали динамический запрос:
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
declare @Field nvarchar(10)  -- передавался параметром хранимой процедуры
declare @sql nvarchar(max);

set @sql = N'
select Table.' + @Field + ', ...
from Table inner join ...
group by Table.' + @Field;

exec sp_executesql @sql


Так вот это стало работать минимум 40 секунд, а в среднем ближе к минуте. При этом и Field1 и Field2 были в индексах и без динамического запроса все работало одинаково быстро. Вы скажете: можно было сделать 2 запроса и разделить их по IF – ELSE. Да, – ответим мы, - только вот уже через неделю у нас было бы более 20 вариантов одного и того же запроса. А динамический запрос продолжал работать примерно минуту.
Вот отсюда печаль в глазах. 

maytonLifecycle любой сложно системы ... связан с ее пожизненной неоптимизированностью.
Да, понимаю. Только ведь хочется сделать лучше хотя бы на чуть-чуть!

White Owl2) Нанять профессионалов.
Лучший вариант с моей точки зрения. Но моя точка зрения не совпадает с мнением руководства, которому надо
White Owlвот здесь и сейчас
и это не обсуждается.

maytonВ трендах современного времени ... NoSQL
Знания на нуле. Буду читать.

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

Подскажите, пожалуйста, товарищи знатоки, как-то можно избежать описанных проблем с динамическими запросами?
...
Рейтинг: 0 / 0
21.03.2015, 17:28
| Ответить | Цитировать | Написать  
Произвольная таблица
    #38912017
Dima T
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dima T
Участник
BercofТак вот это стало работать минимум 40 секунд, а в среднем ближе к минуте. При этом и Field1 и Field2 были в индексах и без динамического запроса все работало одинаково быстро. Вы скажете: можно было сделать 2 запроса и разделить их по IF – ELSE. Да, – ответим мы, - только вот уже через неделю у нас было бы более 20 вариантов одного и того же запроса. А динамический запрос продолжал работать примерно минуту.
Не надо переоценивать возможности MS SQL в переваривании сложных запросов. Он это хорошо делает далеко не всегда. Разбивай на последовательность из нескольких запросов с сохранением промежуточных результатов во временные таблицы и скорость может вырасти на порядки. Именно сохранение во временные таблицы (select ... into #temp), а не подзапросы, чтобы не дать ни одного шанса облажаться оптимизатору запросов.
...
Рейтинг: 0 / 0
21.03.2015, 17:40
| Ответить | Цитировать | Написать  
Произвольная таблица
    #38912741
Фотография SashaMercury
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SashaMercury
Участник
Ребята, вы действительно все считаете что для такой задачи требуется такая реализация ? Вы действительно считаете что актуальным в данном конкретном случае является динамическое добавление атрибутов ?

У него задача на уровне реализовать телефонную книгу, с динамическими атрибутами
...
Рейтинг: 0 / 0
23.03.2015, 02:10
| Ответить | Цитировать | Написать  
Произвольная таблица
    #38912744
booby
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
booby
Участник
ИзопропилBercofДинамический запрос будет каждый раз разный, соответственно SQL сервер не сможет корректно использовать статистику для оптимизации
это называется "преждевременная оптимизация"

...

Нет-нет. Это не "преждевременная оптимизация" называется, а - "оптимизация от испуга".
Ребят всего лишь попросили добавить два вида приоритетов, а они сразу [типы параметров] и [значения параметров]
родили.
Т.е. - произошел испуг от появления первых дополнительных пожеланий и, как естественная реакция на такой испуг,
немедленно вырождена конструкция под все возможные будущие хотелки навсегда.

И не просто породили, а породили с готовым знанием, что запросы теперь обязаны стать динамическими .
Правда, не сообщили здесь - из откуда искусственный интеллект знание о зависимости пользователя от его параметров будет извлекать, чтобы подходящий "динамический" запрос сотворить.


Сидор Артемьевич Ковпак о чем-то подобном подозревал, когда попросил вышедших в лесу на него бойцов отряда Семена Руднева (кадровых военных) немедленно провести занятия со своими партизанами по борьбе с танками.
Поясняя дело примерно так:
Люди мои танков никогда не видели. От того у них может быть большое удивление. А от большого удивления большая дрисня происходит.
...
Рейтинг: 0 / 0
23.03.2015, 02:51
| Ответить | Цитировать | Написать  
10 сообщений из 10, страница 1 из 1
Форумы / Программирование [игнор отключен] [закрыт для гостей] / Произвольная таблица
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=16&msg=38907720&tid=1341061]:
 0ms
get settings:
 9ms
get forum list:
 19ms
check forum access:
 4ms
check topic access:
 4ms
track hit:
 168ms
get topic data:
 9ms
get forum data:
 2ms
get page messages:
 48ms
get tp. blocked users:
 1ms
others: 217ms
total:  481ms
созд. / загр.: 481ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]