OOP design and Databases.

[idefix]

Hi, my first post here.
I would like to make a program that's able to extract words from sentences and determine them grammatically.
Therefore, I made a hierarchy: a base class "Word" from which classes as "Verb", "Substantive", ... are derived (and so for all the categories of words). This seems logical to me because a substantive IS a word. I want to put these words in a database (MySQL). This database has one main table which contains all occurrences of all words. In addition to this, there are tables for each category: a table "Verbs", a table "Substantives",...

Now, the logics for retrieving words from the database or to add a new word to the database, should be handled by the objects (words in this case) themselves. According to Ivor Horton ('Beginning Java 2') this is the right object-oriented way to do things.

My question is: do I put the database handling logic in the parent class (Word) or in the derived classes ("Verb", "Article",...)? Each approach has his advantages: if the program processes a sentence and encounters a new word, it has no idea of the category.
On the other hand, when the program adds a new word to the table, it should be aware of the category, in order to put the word in the right table.
I'm in doubt which approach is the best? Or can you put a part of the database-transfer-logic in the parent class and a part in the derived class?
But this seems somewhat "artificial" or "unnatural" to me. I've been asking myself if there are maybe situations where OOP isn't appropriate? (On the other hand, grammatical structures lend themselves very well too OOP)

I've put it in "New to Java", because I'm quite new to Java. Thank you for your thoughts.

[r035198x]

Don't put any database logic in the Words at all. Words have nothing to do with databases. Let them be reusable classes that model the grammatical structures you are dealing with. Create separate DB access classes that do the DB work.

[idefix]

Don't put any database logic in the Words at all. Words have nothing to do with databases. Let them be reusable classes that model the grammatical structures you are dealing with. Create separate DB access classes that do the DB work.

Thank you for your answer, r035198x, but Ivor Horton writes (in "Beginning Java 2") that this approach "does leave quite a lot to be desired". He says that the other approach is better because the class itself is responsible for ensuring that the correct mapping is performed between the object and the database.
Don't get me wrong, I am the the beginner, I am not trying to teach you. And intuitively I would prefer your approach, because it feels more natural (i.e. closer to reality).
But there seem to exit different opinions on how to implement OOP.

[r035198x]

...
But there seem to exit different opinions on how to implement OOP.

To a certain extent yes. You need to learn all approaches since you are new. You will realize later that most of the time the scenario will dictate which approach should be used. The more approaches you know the better a developer you will be.

[idefix]

To a certain extent yes. You need to learn all approaches since you are new. You will realize later that most of the time the scenario will dictate which approach should be used. The more approaches you know the better a developer you will be.

OK, thank you, r035198x, I'll take the approach you suggest here (making apart classes for DB access)