The savings that you're getting from creating your own surrogates are because of the architecture, not anything inherent in SQL. We inherited a UNIX model of files based on magnetic tapes. This is why we have an IDENTITY table property, that the tables in a single schema are disjoint and have to be indexed separately, and so forth. This is not the only model for SQL, and certainly not the best one for performance or storage.
I'm probably one of the people who still remember WATCOM. It was a spinoff from the University of Waterloo in Canada. They produced a C compiler that out-performed Microsoft and generated some of the smallest, tightest code possible. They also produced an SQL compiler. The University produces some of the best systems programmers I've ever worked with, but they could not do a good human interface.
Their SQL product knew the difference between a referenced and referencing table. The referenced columns in the key were materialized (one way, one place, one time) then the referencing tables built pointer chains back to that occurrence. Basically, they took a lesson from the old network databases. This meant that no matter how big the key was, the references to it used a simple pointer. It also meant doing joins on primary and foreign keys is fast and cheap (we got really good with pointer chains back in the old network days!). DRI actions to cascade the updates or deletes were also insanely fast; you simply change the reference and left the pointers alone.
Please post DDL and follow ANSI/ISO standards when asking for help.