3 ms·
How many millions, or billions, of database users are you comfortable managing? 0 millions for me. I'll stick with the well tested and explored method of havi
by falcolas 6y ago
How many millions, or billions, of database users are you comfortable managing?
0 millions for me.
I'll stick with the well tested and explored method of having a users table with foreign keys on the ID to other tables to identify data ownership.
The idea of using one DB user per end user is, at best, novel and untested. We don't know where or how it will fail. Scaling would be a real bear too. And I'm fairly certain an InfoSec professional would have kittens if they saw that attempted in a production environment.
- dragonwriter 6y ago> The idea of using one DB user per end user is, at best, novel and untested Its a technique older in continuous use with RDBMSs and more battle-tested than, say, the web itself, and plenty of enterprises (even the kind that have apps that not only don’t provided direct DB access to their frontend, but don’t even provide their backend access to tables or views but mediate all external access to the DB through sprocs) have it as a security norm and (correctly) view apps that manage end-user access outside of the database as taking a relatively novel, untested, and risky approach.
- zerg2k 6y agoLooks like you have some knowledge hole. Let’s start with MSSQL you can use AD groups and those are the one and only thing that database setups are concerned with. On the AD side users get added/removed all the time. I have personally managed this kind of system with nearly “0” overhead on the DB side. Group assignment is the maintained by team managers decentralizing the whole thing. For non Kerberos Linux systems using LDAP to synchronize group membership is the only extra automation needed. It is possible and fairly easy to manage a very large number of accounts IF done properly.