I work with a non-profit group that lists business members on our website. I''m creating a simple Rails app to track those memberships & expire the listings when their membership expires. Our actual membership info is managed in an offline access database, and only a small percentage of the members will go into the web database. So it seems like I have two options for my database design: Either manually enter the ID number so it coincides with the one in the Access database, or use an auto_increment ID field and a separate member_id field. I seem to recall reading that the ID field must be auto_increment, but that second option seems confusing & just bad. So will I run into problems if I just manually create the ID value? Obviously they need to be unique, but are there any other issues?
On Mon, 20 Jun 2005 12:58 pm, Mike Payson wrote:> So will I run into problems if I just manually create the ID value? > Obviously they need to be unique, but are there any other issues?Nope, that will work fine. You could even add validation to your model class to ensure that you can''t save a model instance without first setting it''s id. That way, there''s no danger of accidentally using the auto-increment feature (and thus potentially using up an id which is used in your access database). However, if you ever intend to have any of these items in your web database which aren''t in your access database, then this method isn''t for you. In that case, I''d go with the second field option that you described. It wouldn''t be the primary key, but you could still put a unique index on it so that searches would be fast and the uniqueness constraint would be enforced. I don''t think that this option is dodgy as you think. :) Actually, I think that it''s quite good, because it reduces the coupling between your two seperate applications. Craig -- Craig Ambrose Web Elements http://www.portallus.com/people/craigambrose/
> However, if you ever intend to have any of these items in your web database > which aren''t in your access database, then this method isn''t for you. In that > case, I''d go with the second field option that you described. It wouldn''t be > the primary key, but you could still put a unique index on it so that > searches would be fast and the uniqueness constraint would be enforced. I > don''t think that this option is dodgy as you think. :) Actually, I think that > it''s quite good, because it reduces the coupling between your two seperate > applications.That makes sense. In its current mission, that would never happen. But there is some chance that this could expand to replace the access database altogether, so I guess it makes sense to just assume it will from the beginning. Thanks!