Relationship Components

Much of the arguments passed to any of the sqlRelationship objects will be strings. However, upon my initial analysis, there are a couple of potential arguments that may benefit from an encapsulation into a class. This will help not only with conversion of these arguments to strings for inclusion into the SQL statement, but for validating the passed argument is of the correct type within the sqlRelationships. My first thought is to create class definitions for column definitions and functions.

Column definitions will contain an sqlTableReference object and a column name. The table object will contain the table name to be joined with the column name within the __toString() method.  Function objects will process the __toString() method depending upon the function being requested. This is the perfect opportunity for encapsulation. We may be able to add some future formatting validation to prevent function syntax errors.  By creating classes for these argument types we allow for easy future enhancements.

Other argument types like values and expression will be passed as simple strings. The abstract parent sqlRelationship class will perform basic scrubbing to prevent invalid or malicious code from being passed via these strings. The last argument type, an SQL object, is an object in itself and no need to create another class to hold this type.

With some further expansion with the relationships between the classes, my new UML Diagram is shown below. You will notice that the sqlFunction object can be composed of multiple sqlFunction objects to create complex embedded functions.  I have also decided to extend the sqlWhereCondition into the sqlOnCondition instead of it being an extension of the sqlRelationship abstract class. The sqlOnCondition, in turn, is composed of multiple where conditions. This may prove to be incorrect later, but I will stick with it for now.


Leave a Reply