Отчеты о сортировке и фильтрации

Question

Есть ли какой-либо известный шаблон/алгоритм, как правильно сортировать или фильтровать список записей (из базы данных)? Моя текущая попытка связана с использованием формы, которая предоставляет некоторые параметры фильтрации и сортировки, а затем добавляет эти критерии и алгоритм сортировки к существующему SQL. Тем не менее, я считаю, что можно легко злоупотреблять тем, что пользователи могут получить результаты, которые они не должны видеть.

Приложение, которое я создаю, представляет собой планировщик, в котором хранятся все события в таблице базы данных. Затем в зависимости от уровня пользователя/роли/привилегии будет отображаться другой поднабор данных. Поэтому мой запрос может быть так сложно, как

SELECT * 
FROM app_event._event_view 
WHERE ((class_id = (SELECT class_id FROM app_event._ical_class WHERE name = 'PUBLIC') AND class_id != (SELECT class_id FROM app_event._ical_class WHERE name = 'PRIVATE') AND class_id != (SELECT class_id FROM app_event._ical_class WHERE name = 'CONFIDENTIAL')) OR user_id = '1') 
     AND calendar_id IN (SELECT calendar_id FROM app_event.calendar WHERE is_personal = 't') 
     AND calendar_id = (SELECT calendar_id FROM app_event.calendar WHERE name = 'personal') 
     AND state_id IN (1,2,3,4,5,6) AND EXTRACT(year FROM dtstart) = '2008' 
     AND EXTRACT(month FROM dtstart) = '11' 

Поскольку я больше заботы о служении правильное подмножество информации, производительность не является серьезной проблемой в данный момент (как SQL упоминалось был сгенерирован скриптом, п по пункт). Я имею в виду превратить все эти сложные SQL-предложения в представления, поэтому будет меньше шансов, что генерируемый SQL не подходит.

Answer 1

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

Но если privilegues являются «одномерный», например, Администраторы могут видеть все, что пользователи могут видеть мощности меньше, чем админов, гости могут видеть меньше опытных пользователей, и т.д .: Вы могли бы, вероятно, реализовать privilegues как целое число в обоих случае и пользователем, а затем

select from event where conditions AND event.privilegue <= user.privilegue 

Если вы устанавливаете значения privilegue примерно как 10 000 (высокий/админ), 5000, 1 (самый низкий/гость), вы можете впоследствии добавить еще несколько уровней без изменения всего кода.

Answer 2

Использование ORM инструмента или использовать такие параметры, как:

SELECT * 
FROM app_event._event_view 
WHERE 
    (
     :p_start_year is null or 
     (state_id IN (1,2,3,4,5,6) AND EXTRACT(year FROM dtstart) = :p_start_year) 
    ) 
    and 
    (
     :p_date_start is null or 
     AND EXTRACT(month FROM dtstart) = :p_date_start 
    ) 

Answer 3

Во-первых, этот запрос будет выглядеть и работать лучше, если вы используете присоединяется:

SELECT * 
    FROM  
    app_event._event_view EV 
    INNER JOIN app_event.calendar C 
     ON EV.calendar_id = C.calendar.id 
    INNER JOIN app_event._ical_class IC 
     ON C.class_id = EV.class_id 
    WHERE 
    C.is_personal = 't' 
    AND C.name = 'personal' 
    AND state_id IN (1,2,3,4,5,6) 
    AND EXTRACT(year FROM dtstart) = '2008' 
    AND EXTRACT(month FROM dtstart) = '11' 
    AND (
     IC.name = 'PUBLIC' -- other two are redundant 
     OR user_id = '1' 
     ) 

Это хорошее начало для поддержания сложности вниз. Затем, если вы хотите добавить дополнительные фильтры непосредственно в SQL, вы можете добавить в конце больше операторов «AND ...». Поскольку все критерии связаны с AND (OR безопасно содержится в круглых скобках), нет возможности, чтобы кто-то добавил критерий после них, который каким-то образом отменяет те, что были выше, то есть после того, как вы ограничили результаты одной частью , вы не можете «запретить» его с помощью более позднего предложения, если оно связано с AND. (Конечно, если эти дополнительные предложения идут куда ближе к пользовательскому текстовому вводу, вы должны их дезинфицировать, чтобы предотвратить атаки SQL-инъекций.)

База данных может фильтровать быстрее, чем любой другой уровень, в общем, поскольку использование предложения WHERE на база данных часто позволяет базе данных избегать даже чтения ненужных записей с диска, что на несколько порядков меньше, чем все, что вы можете сделать с процессором. Сортировка также часто выполняется и в БД, поскольку БД часто выполняет объединения таким образом, что записи уже отсортированы в том порядке, в котором они вам нужны. Итак, производительность разумна, если вы можете сделать это на БД, тем лучше.

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