You read it right...I designed a big database around a main "Customers" table with a PK that is an indexed (no duplicates) text field containing "Lastname Firstname". At the time, I didn't know it was frowned upon, and I didn't think I could handle working with "blind numbers" holding my tables together. I was teaching myself as I went along, but I needed those customer lists working right away. (I also started with some look-up fields in my tables, but I got rid of those pretty quick before things got complicated.) I do have autonumber fields (ID) in all of my tables, and they are the PK in some of them. When the dreaded duplicate-named client comes along, I was just going to "manipulate" customer names to avoid duplicates (luckily it doesn't violate our business rules) such as using given name vs. "name used", or including a middle initial.
In any case, other than the potential for a duplicate client name, my database is working very well doing some very fancy billing and time usage calculations, multiple tiered queries, complex forms, etc. I am using cascade update (but not cascade delete) to keep everything matching up. It would be a huge job to switch the database over to an autonumber PK but I'm wondering if I should do something like making a composite key with the ID and the name. The tutorials and explanations of that confuse me a bit. I understand if I did that, I'd have to add the autonumber field in to all of the tables in addition to the existing text name field, but the joins and relationships I'm not sure about.
Do you think it's worth the effort to figure this out and go to a composite key?