Въпреки че вашата логика и горните решения са добри за малък мащаб, ако говорите за повече от 65 000 елемента, имате нужда от решение, което е мащабируемо.
Моето предложение е да разделите тази задача на 2 стъпки.
Стъпка 1
Създайте временна таблица. Тази временна таблица ще има минимум 3 колони
TEMP_ITEM_ORDER_TABLE (
session_key varchar2(50),
item_id number,
item_report_order number
)
Всеки път, когато потребителят поръчва такава заявка, вмъквайте данни, т.е. идентификационни номера на елементи и техния номер на последователност в тази временна таблица с някакъв уникален ключ за идентифициране на потребителска сесия (евентуално потребителски идентификатор или идентификатор на сесия). Този трик е да се избегне сблъсък на списъци с елементи, когато множество потребители едновременно задействат отчети.
Стъпка 2
Сега задействайте вашата заявка за отчет, присъединявайки се към вашата основна таблица, временна таблица с session_key . В данните за реда на заявката въз основа на вашия входен ред (вече съхранен във временната таблица)
SELECT
T1.* , T2.item_report_order
FROM ITEM T1, TEMP_ITEM_ORDER_TABLE T2
WHERE T1.ITEM_ID = T2.ITEM_ID
AND T2.session_key = :input_session_key
ORDER BY t2.item_report_order
Този метод е
- агностик на база данни
- мащабируем с произволен брой входове
- Осигурява възможно най-добра производителност
Забележка:За да подобрите допълнително производителността на заявката, създайте индекс на session_key, item_id във временната таблица също създайте индекс на item_id в таблицата ITEM (ако вече не съществува)
Редактиране:Oracle предлага Глобална временна таблица функция, която създава, има функции за разрешаване на записи само в сесия и автоматично почистване при извършване/край на сесия и т.н. Можете да използвате тази функция и да избегнете сесийния ключ, но това решение не може да бъде възпроизведено в други продукти за бази данни, освен ако те поддържа подобна функция.
