Table and field names should be descriptive of the domain entity that they capture. If the domain entity is a customer, you should call the table "Customers." Like classes in an object-oriented program, tables follow the Single Responsibility Principle: each table should store instances of one thing (with all of its attributes), and one thing only.
To see why this is so, imagine the complete opposite. Imagine a system so generic that it's all stored in just three tables:
TableID Primary Key
FieldID Primary Key
TableID Foreign Key
Type Enum (Text, Number, etc.)
ValueID Primary Key
FieldID Foreign Key
Notice that there's no identifying information at all in the tables themselves. You have to run a query to find the table you want. Then, you have to run another query to get the field that you want, and a third to get the field value.
If this looks familiar, it should: the first two tables are basically the "system" tables in an ordinary DBMS, which we have now re-invented. In fact, we have reinvented the entire DBMS. If you doubt this could ever happen, read here: