NUraКаждый пользователь оперирует только своими данными, с данными других пользователей не пересекается, доступ к данным другого пользователя нужно ограничить.
По опыту, я скептически отношусь к "не пересекается". Если не имеется в виду некое подчеркнутое юридическое или фактическое разделение - скажем, это не независимые люди, работающие в некоторой "веб-БД", то постепенно начинают пересекаться.

NUra1) Создается единая база для всех пользователей, в нее входит N таблиц, в каждой записи таблиц указано IDпользователя. Для работы с данными пользователя (мы знаем его ID) программно формируется запрос select, который фильтрует записи по ID.
В принципе нормальный способ, только нужно не "формируется select", а "работать через view или ХП". Это и удобнее, и надежнее.

Ну а учитывая наличие в Ваших постах Oracle-доминанты, возникает вопрос, почему Вы избегаете стандартного решения от вендора.

NUra2) Для каждого пользователя создается свой набор N-таблиц. Тогда зная пользователя мы работаем только с его таблицами.
Тоже возможный способ со своими плюсами. Однако, существующая механика СУБД мало приспособлена для работы с такими структурами. В частности, придется либо отказываться от хранимого кода, либо тысячекратно его копировать (по сути, организовывать отдельные базы для каждого пользователя). В полном пролете окажется кэш запросов, да и кэш данных будет не столь эффективен. Сервер будет ставить блокировки, которые никто никогда не будет ждать. Запросы "ко всем данным" станет писать весьма тяжело.

В общем - я бы задумался об этом способе только если бы обнаружил серьезные минусы в подходе номер 1.