The Enterprise geodatabase model calls for multiple logins when managing tables.
First off, you should not ever create any tables as the
sde user. Period. Ever. Using administrative accounts to manage tables opens the door to complete database destruction with a single click.
Best practice is to create at least two additional logins (though in practice this expands to two more than the number of independent users).
When using the simplest security model, this means that login/user/schema
data_owner creates and registers tables and login/user/schema
data_user is granted the necessary access to do necessary processing. In this model, the GIS admin/team retains login rights to
data_owner and all others connect as
In the real world, you'll have logins
dept_c manage the holdings of departments, with each real user accessing the database having an individual login, and group roles created to model needed access read-only/read-write, and accesses granted to the roles, with roles granted to users. In addition, there may be one or more login/user/schemas created for "headless access" (ArcGIS Server publishing connections, with roles assigned appropriately).
While most databases support schemas that do not match logins, the geodatabase model can only support this if the user never needs to create a selection set over 100 records, because it will then try to create tables with the same schema/user as login and fail.
Using your example, you should not create tables as
administrator (best practice), and should instead create at least one login/user/schema to own the geodata, and one or more login/user/schemas to access the data. You can then safely create feature classes as the owner account(s) and access them as necessary.
The only possible alternative is to abandon using all geodatabase functionality, and create tables only via SQL tools, never registering them with the geodatabase, and only accessing them via Query Layers (and even then, you shouldn't use the
sde login for this).