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 Qcodo's ORM is that it does
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, Qcodo 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).
Qcodo also offers some
support for tables that have multiple-column Primary Keys defined on it.
For tables that have multi-column Primary Keys, Qcodo 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, Qcodo does not support multi-column Foreign
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
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).