Суть в том, что производительность является ключевым фактором, и мне трудно решить, что индексировать, и может ли это даже помочь мне, учитывая тот факт, что эти парни могут в основном создавать свои собственные запросы с помощью пользовательского интерфейса.
В итоге вы уступаете производительность своей БД прихоти своих клиентов.Если они могут «создать свой собственный запрос», то они могут «создавать свои собственные РЕАЛЬНО ПЛОХИЕ запросы».
Итак, если вы запускаете это в общей среде (то есть на том же оборудовании)то ужасное сканирование таблиц клиента А может насытить ввод-вывод для всех остальных.
Если они находятся на одном и том же сервере базы данных, то сканирование клиента А позволяет сбросить данные всех ваших клиентов из кэша данных..
По сути, чем больше вы «делитесь», тем больше один клиент может влиять на работу других клиентов.Если вы даете клиентам возможность делать дорогие вещи и делиться многими из них, то все страдают.
Итак, варианты таковы: а) не позволяйте покупателям делать глупости или б) держать клиентов какразделены настолько практично, что, когда кто-то делает глупости, телефоны не загораются от всех других клиентов.
Если вы не знаете, «что индексировать», тогда вы не предлагаете большой контрольнад тем, что могут делать клиенты, и, следовательно, фактор глупости возрастает.
Вы, вероятно, довольно далеко продвинетесь, предложив несколько популярных готовых представлений SQL, из которых клиенты могут выбирать, а затем они 'ограничены простой фильтрацией и, возможно, упорядочением результатов.Затем вы оптимизируете выполнение этих представлений.
Вероятно, что удивительно мало "общих" представлений могут охватывать большое количество вариантов использования.
Общие, глупые запросы могут быть делегированы пакетупроцесс, который выполняется в одночасье, в нерабочее время или на отдельном компьютере, который не влияет на производительность транзакций, например ночной снимок с «всем, кроме сегодняшних данных».Пусть они проводят исторические запросы против этого.