These kinds of classes are common in enterprise applications and web development.

If, as you say, this class is providing Create, Read, Update & Destroy (CRUD) operations on a table then you have implemented the Data Access Object (DAO) pattern and I would stick those 3 letters on the end of the class e.g. "HighscoreDao".

There is another, related pattern that operates at a slightly higher level of abstraction from a DAO, it called the Repository pattern. A repository maps between some kind of persistent storage and collections of domain objects, for example a "MonsterRepository" might have to collaborate between multiple database operations in order to provide calls such as getMonstersForLevel.

Finding the verbs in your system and creating classes for them is the classic procedure-oriented antipattern. Not that there's a lot wrong with procedure-oriented design, unless what you're trying for is object-oriented design so you can take advantage of many of its long-term benefits. Using classes and object for procedure-oriented design will bring you and the people who have to maintain your code grief.

In good OO design, you look for the nouns (object) in your system and create classes for them, then look for the verbs that act on the nouns and create functions for them. If you're using your noun in the subjective case, you probably have a member function, and if it's in the objective case, you probably pass it as a function argument. Not a hard-and-fast rule.

Using an agent noun ("eg. a 'manager' is something that performs the action denoted by the verb 'to manage') in place of the verb itself for a class name is still procedure-oriented programming. Classes are nouns, functions are verbs.

My guess is that the original requirement was to be able to insert, remove, or update rows in a table in a relational database, or maybe (key, value) pairs in a persistent lookup table (what the folk who learned all their computer science off marketing whitepapers call a nosql database). I image there are various additional verbs for those nouns for performing metaoperations (like connecting to the RDBMS, fetching a row, committing a transaction).

Just remember: nouns are classes, verbs are functions.

DBManager, with specific functions for deleting, updating, creating etc.

I usually find this sort of class that encapsulates all SQL operations called a DAO; they cover the whole spectrum from dumb and generic (often simple CRUD operations, with the extreme of supporting query builders that write WHERE clauses on the fly) to complex and specialized (e.g. methods executing multiple or different SQL statements depending on data). The common trait is avoiding, or at least abstracting and minimizing, "business" logic that goes beyond accessing data and treating SQL errors.

Typical naming patterns refer to the database tables, under the assumption that different tables have different purposes and DAO changes follow table chages. For example a DAO that operates on the Widget table only can be called "WidgetDAO", while one that combines access to the Widget, Gadget and Screw tables (either because they are considered a logical grouping or because they are actually used together) could be called "MechanicalWorkshopDAO".