Nie mam problemu z używaniem tych samych (lub bardzo podobnych) nazw w adresie URL i bazie danych — z pewnością możesz „ujawniać” szczegóły implementacji, ale jeśli wybierasz radykalnie różne nazwy w adresie URL i w bazie danych, prawdopodobnie wybierasz złe nazwiska. Jestem też fanem spójnego nazewnictwa — komunikacja z programistami/testerami/klientami staje się znacznie trudniejsza, jeśli wszyscy nazywają wszystko nieco inaczej.
Co mnie wkurza, to to, że pozwalasz użytkownikowi uruchamiać dowolne zapytania w Twojej bazie danych. http://.../index.php?table=users&user_id=1 , mówić? Lub http://.../index.php?table=users&password=password (nie, że powinieneś przechowywać hasła w postaci zwykłego tekstu)? Lub http://.../index.php?table=users&age=11 ?
Jeśli użytkownik podłączony do bazy danych ma takie same uprawnienia jak użytkownik siedzący przed przeglądarką internetową, może to mieć sens. Ogólnie rzecz biorąc, tak nie jest, więc będziesz potrzebować warstwy, która wie, kim jest użytkownik, a czego nie może zobaczyć, a ta warstwa jest o wiele łatwiejsza do prawidłowego napisania dzięki dodaniu do białej listy.
(Jeśli umieściłeś wystarczająco dużo logiki w procedurach składowanych, może to zadziałać, ale wtedy Twoje procedury składowane będą na stałe kodować nazwy kolumn...)
