convore.json/groups/django-community/migrating-legacy-system-preserve-or-migrate-fk/messages.json

[{"user_id": 1822, "stars": [], "topic_id": 11348, "date_created": 1299526619.49072, "message": "I'm currently leaning toward migrating this as an explicit non-fk field, so I can move and rebuild the system between dev-staging-production based on data imports, without having to worry about mucking with the autofields at the DB level.", "group_id": 81, "id": 290047}, {"user_id": 1822, "stars": [], "topic_id": 11348, "date_created": 1299526671.3927369, "message": "I can always recreate the relationships based on these explicit legacy fields, but I'm looking for any input from those with experience with this problem.", "group_id": 81, "id": 290057}, {"user_id": 214, "stars": [{"date_created": 1299528024.8789849, "user_id": 3580}], "topic_id": 11348, "date_created": 1299527286.291497, "message": "The usual advice I've seen is to avoid using fields with semantic meaning for primary keys (and thus by extension foreign keys). Makes your schema more brittle and less flexible to future changes in the semantics. So yeah, I'd say move away from using those fields as FKs if you can.", "group_id": 81, "id": 290220}, {"user_id": 1822, "stars": [], "topic_id": 11348, "date_created": 1299526550.8549559, "message": "I'm in the process of starting to migrate a legacy system to Django.  There are a number of fields which are defacto fk - even though they are used explicitly by end-users (ie student id).", "group_id": 81, "id": 290029}, {"user_id": 1822, "stars": [], "topic_id": 11348, "date_created": 1299526703.7248099, "message": "Part of this, is we will be transitioning over time, so I'm picking peripheral modules/models and will be syncing a proxy core model with the legacy system for some time.", "group_id": 81, "id": 290065}, {"user_id": 3580, "stars": [], "topic_id": 11348, "date_created": 1299528074.3278561, "message": "I totally agree with @carljm .. Further, if you're going to take on the pain of the migration anyways.. I'd consider moving to a shared-id space (all pks are unique, across tables). I just moved our system to one, and it's already paying dividends.", "group_id": 81, "id": 290397}, {"user_id": 1822, "stars": [], "topic_id": 11348, "date_created": 1299532544.93839, "message": "@phill so are you using a uuid as a pk?", "group_id": 81, "id": 291322}, {"user_id": 3580, "stars": [], "topic_id": 11348, "date_created": 1299543395.763478, "message": "no, we're using a 64bit int.", "group_id": 81, "id": 292615}, {"user_id": 3580, "stars": [], "topic_id": 11348, "date_created": 1299543452.4275329, "message": "(in our case, we got a bit fancy. the high 48 bits are globally unique, and the lower order 16 bits are a type code). I'm not sure I'd suggest that level of fanciness though.. we've yet to live with that part for very long.. but so far it seems pretty okay :)", "group_id": 81, "id": 292626}, {"user_id": 19105, "stars": [], "topic_id": 11348, "date_created": 1299577793.638077, "message": "@phill How do you enforce that in code?", "group_id": 81, "id": 295100}, {"user_id": 3580, "stars": [], "topic_id": 11348, "date_created": 1299602356.2003441, "message": "@andybak There are a number of different ways, I guess.. but we kept it simple. There's a single mysql table that has an autokey on it. We insert there first, retrieve the key and then insert the concrete table. Sounds more expensive than it is. If you had really high synchronous insert volume (we don't) you could stand up some 'keymasters' that transactionally grab a set of keys in batch and dole them out very quickly. Or I suppose atomic counters in Redis or something similar would be an approach also.", "group_id": 81, "id": 297417}, {"user_id": 3580, "stars": [], "topic_id": 11348, "date_created": 1299603042.9888639, "message": "@andybak didn't occur to me that you might have been asking a slightly different question.. Structurally we've got an 'Entity' base-class that all of the models that participate in this keyspace inherit from. It does all the magic related to getting them their appropriate key.", "group_id": 81, "id": 297477}]