of database credentials or having different area, including duplicate pages, that handle the different database credentials.
Why would you have duplicate pages? You store the database connection credentials in a session, or even the database connection object. When they login, they change credentials and run with those.
The user can see the table structure, perhaps the view definition, but not the data they have no rights to.
You deny select on the table, and grant access to the view. The view contains a constraint that forces the view only to return the data the connecting user is allowed to see.
I have implemented this in Postgres/PHP.
You have a group role that has read access to the public tables (eg products). The webserver runs, by default, at this user level.
When a user logs in, they reconnect to the database. They are in two groups now, the same one the webserver runs in by default, and another, which gives them access to their view
To CREATE users, you have an insert trigger in a users table to which the webserver user has INSERT rights, which then creates a new role with the required credentials.
Is it more work than a simple users table and single sign on? Yes. Is it a more sound methodology than SSO? Yes.
You wouldn't have SSO in a corporate environment, why should you have it in a web environment?
If your code is running at the correct privilege level, SQL injections should be completely irrelevant.
If your user is connecting with the correct credentials, they should only be able to see public data and their own records, nothing else.
This is implemented by using views in the database, and only allowing users rights to views, not tables.
If your website user is connecting with credentials that allow a crafted SQL query to see priveleged data, you have set everything up wrong
If you have set everything up correctly, even a successful SQL injection will only return data the user can see
And then testing involved aspects of system performance which simply don't apply in many environments today - memory leaks, null pointer exceptions, DLL hell, and so on. There was a much stronger case for a more rigorous and pedestrian process, because the costs of change were higher. Being able to change and test code on the fly is something to to be taken advantage of.
That doesn't mean methodology should be thrown out of the window. A solid, lean, clean, transparent, demarcated set of classes to describe the general system and initial problem will give you flexibility to change. Keep your business, data and presentation layers separate. Always maintain stable interfaces. It doesn't have to be dogmatic.
If hate isn't a crime, why is inciting hatred a crime? This is one question the liberal fascists can't answer. Inciting violence is a crime, because violence is a crime, commissioning a crime is a crime. But hatred?
Liberals, not being people who like taking responsibility for their own actions, like the idea that nebulous things such as "speech" can be held responsible for events. Ergo, punish the speech.
The problem with "inciting hatred" is that it's such a nebulous term that anything can be interpreted in that way by even the most hypersensitive paranoiac and before you know it, you're not saying anything for fear of being arrested. For some people, saying that sodomy is grotesque is enough to merit a penalty.
Britain's Labour government are a sad, sad, desperate, miserable bunch of barrel scraping nation destroyers. We were owed an election years ago.