On Wed, 30 Jul 2014, Michael Bayer wrote:
With that, plus the predictable indexing, I'm always going to use them. But, I think there's a fair degree of preference still here. With natural PKs, the biggest issue is how much space indexes are going to take up considering that everything that FKs to that PK has to mirror out those same columns.
Mike, Fair enough. In the current application I'm developing most tables will have comparatively few rows (< 500 in most cases). The data tables can easily have > 100,000 rows, but the only table that would relate to those is the 'changed' table which records what, when, why, and by whom a change was made. This is for audit trail purposes. Thanks for your insights, Rich -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To unsubscribe from this group and stop receiving emails from it, send an email to sqlalchemy+unsubscr...@googlegroups.com. To post to this group, send email to sqlalchemy@googlegroups.com. Visit this group at http://groups.google.com/group/sqlalchemy. For more options, visit https://groups.google.com/d/optout.
