On OOP, Relational DBs, and DBRow.

DBRow is the representation of a table and its structure.

A fundamental difference between Object Oriented Programming and Relational Databases is that DBs are based on persistent tables that store information. OOP however generates a process that creates transient information.

In Java the only persistent concept is a class, so DBvolution represents each table as a class. Each column of the table is represented as a Java field. Connecting the class and fields to the table and columns are annotations: DBTableName & DBColumn.

Java and Relational datatypes differ considerably, not the least because each DB has it's own unique version of the standard datatypes. Also DB datatypes are much more weakly typed. DBvolution uses QueryableDatatypes (QDTs) to bridge the gap between Java and Relational. The most common QDTs are: DBString, DBInteger, DBDate, and DBByteArray.

Relational databases deliberately eschew hierarchies and has very weak links between entities with enormous number of entities. Conversely Java is filled with hierarchies and strong links while having a, relatively, tiny number of entities. These incompatibilities can only be resolved by avoiding a hierarchy, keeping the links relatively weak, and only retrieving the entities that have been requested to keep the number of entities relatively low.

Hierarchy is avoided by not directly using any DBRow subclass within a DBRow subclass. Extending a DBRow subclass has it's uses but there is still little connection between the classes.

Weak linking is achieved using the DBForeignKey annotation with the class of the related class. Foreign keys connect to the primary key (see the DBPrimaryKey annotation) of the other class to allow NATURAL JOINS but don't connect the classes directly and can be ignored using DBRow.ignoreForeignKey(java.lang.Object).

Reducing the number of entities is facilitated by making it easy for you to specify the tables required and add conditions to the queries.