# New rails project with legacy DB (sort of) **URL:** \ **Category:** Rails\ **Created:** [May 5, 2010, 11:24pm UTC](https://www.ruby-forum.com/t/new-rails-project-with-legacy-db-sort-of/188111 "2010-05-05T23:24:43Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![agilehack](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/d2c977/32.png) [@agilehack](https://www.ruby-forum.com/u/agilehack)\ **Post date:** [May 5, 2010, 11:24pm UTC](https://www.ruby-forum.com/t/new-rails-project-with-legacy-db-sort-of/188111/1 "2010-05-05T23:24:43Z")
I am starting a new rails project and have been given a DB with data etc. The good news is that the data is not being used by any other system so even though the DB has been designed and given to me I have liberty to change as needed. My goal would be to tweak the DB before starting to work well follow rails conventions. I will change table names and add the created\_at, modified\_at fields manually. My issue comes in with the ID field/primary key. I would love to add the ID field as primary key and auto\_increment so that I can create my Rails app fresh and everything works as if I created through a migration. Trouble being that each table already has a primary key, usually \ and that field also exists in other tables. So I cant just change the field name to ID. But since the DB isn’t being used by any other system, can I just create a new column named ID and make it the primary key(auto\_increment) and remove the primary key status from the existing? In this scenario all the data given to me remains intact I just create and change the primary key. Or would this destroy the data relationships of these table and cause more issues down the road? ---
**Author:** ![agilehack](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/d2c977/32.png) [@agilehack](https://www.ruby-forum.com/u/agilehack)\ **Post date:** [May 5, 2010, 11:32pm UTC](https://www.ruby-forum.com/t/new-rails-project-with-legacy-db-sort-of/188111/2 "2010-05-05T23:32:19Z")
Why not start from scratch with a rails-created database, then import the old data into it? Seems like it’d be the least pain solution. Larry ---
**Author:** ![agilehack](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/d2c977/32.png) [@agilehack](https://www.ruby-forum.com/u/agilehack)\ **Post date:** [May 6, 2010, 3:08pm UTC](https://www.ruby-forum.com/t/new-rails-project-with-legacy-db-sort-of/188111/3 "2010-05-06T15:08:51Z")
that is a great idea and I had that thought. It has several tables and some of the table many fields so is there an easy way to do that? Do you think taking a SQL dump of the DB and then copy paste most it into the migration file and then run rake db:migrate?? any other suggestions? I would think this is a very common thing amongst rails developers being that often you are given the data or some of it, regardless of if the DB is already relied upon or not - wanted to make sure I was doing things smartly ---
**Author:** ![agilehack](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/d2c977/32.png) [@agilehack](https://www.ruby-forum.com/u/agilehack)\ **Post date:** [May 6, 2010, 10:40pm UTC](https://www.ruby-forum.com/t/new-rails-project-with-legacy-db-sort-of/188111/4 "2010-05-06T22:40:33Z")
agilehack wrote: > that is a great idea and I had that thought. It has several tables > and some of the table many fields so is there an easy way to do that? > Do you think taking a SQL dump of the DB and then copy paste most it > into the migration file and then run rake db:migrate?? No way! That will just keep the old schema. (But see below.) > any other > suggestions? I would think this is a very common thing amongst rails > developers being that often you are given the data or some of it, > regardless of if the DB is already relied upon or not - wanted to make > sure I was doing things smartly The smart thing to do: - Look at the old DB. - Understand the data in it. - Figure out a way of modeling that data that Rails will like. - Write migrations to create a new DB from scratch. (It might look nothing like the old one.) - Import data as appropriate. Alternatively, start by duplicating the legacy schem as you suggested, then refactor it bit by bit. ## Best, Marnen Laibow-Koser [http://www.marnen.org](http://www.marnen.org) removed\_email\_address@domain.invalid