>>It's an idea worth some time. I don't think anything is going to make this a less onerous task though. I have to manually create all the indices, and the way they've set it up, in far too many cases, the tags themselves are going to look like Str(IntegerField1) + Str(IntegerField2) because uniqueness depends on more than one integer field - that is, unless you know an easier way of compounding integer fields into an index tag.
>
>Not easier, but more efficient:
>
>Instead of
>
>

>str(IntField1) + str(IntField2) && 20 bytes
>

>
>use:
>
>

>bintoc(IntField1) + bintoc(IntField2) && 8 bytes
>

But more typing. Carpal Tunnel, here I come.

>
>> And then the foreign key indices will have to follow the same pattern. I'd like to get my hands on the person who came up with the SQL database design.
>
>Yeah, it looks like a real pain in the acronym. But - can't you add an integer key yourself? For the foreign keys, you will have to do a lookup in the table that contains the primary keys, but it may save you trouble in the long run.

I thought about that, but in order to relate the various child tables back to the parent table in order to add the new primary key as a foreign key, I still have to match their foreign keys back to their own stupid primary keys. And it's not as if there is one child table per parent, nor even one grandchild to one child. With all the manual work I have to do on this, I doubt doing that will really save me much time, if any.