Primary Keys in Your Tables

In order for any ORM architecture to work, there must be at least some kind of primary key defined on any table for which you want an object generated. But what is unique about Qcubed's ORM is that it does not impose any requirements on how to define your primary keys. (Note that you can also still use the framework against any database that contains tables that do not have primary keys, it is just that those specific tables will not be generated as objects.)

Your primary key column or columns can be named however you wish. Moreover, Qcubed supports primary key columns that are both "automatically incremented" and not "automatically incremented". ("Automatically incremented" columns are known as auto_incremement, identity, or using a sequence, depending on which database platform you are using).

QCubed also offers some support for tables that have multiple-column Primary Keys defined on it. For tables that have multi-column primary keys, QCubed will fully generate the object itself. But note that you will not be able to use this generated object as a related object for another table (in other words, QCubed does not support multi-column foreign keys). However, with all the generated Load methods in these objects, it is still possible to fully develop an application with tables that use multi-column foreign keys. Basically, whenever you want to access a related object via a multi-column foreign key, you can simply call that object's load() method directly to retrieve that object.

If you are code generating against a legacy application or database that has tables with multiple-column primary keys, then this level of support should hopefully suffice. But if you are creating a new application or database, then it is recommended that all tables have a single-column primary key (with one that preferably is sequenced, auto_increment, or identity, depending on which DB platform you are using).