В моей /db папке моего приложения rails (rails 2.3.4, ruby 1.8.7) есть development_structure.sql, и я точно не знаю, что он делает.
Нельзя добавлять его в репозиторий git.
Это файл, созданный автоматически рельсами при запуске миграции с помощью вашей базы данных, настроенной для подключения к базе данных mysql. Вы можете просмотреть его в качестве альтернативы schema.rb
Я считаю, что вы можете заставить рельсы создать его, добавив в свою среду .rb:
config.active_record.schema_format = :sql
При наличии этого файла используется, например,:
rake db:test:clone_structure
Edit
Соответствующий раздел в руководствах Ruby On Rails. http://guides.rubyonrails.org/migrations.html#schema-dumping-and-you
Они рекомендуют проверить его в исходном коде на вики.
Мне лично нравится, чтобы это не было. Мне нравится очень быстро запускать все миграции. Это для меня хороший знак. Если миграция замедляется, я чувствую, что больше не контролирую окружающую среду. Медленность в миграции обычно означает, что у меня много данных в моей базе данных разработки, которые я чувствую не так.
Однако, похоже, сейчас это вопрос личного вкуса. Следуйте своим инстинктам на этом.
Это сообщение было использовано в качестве ссылки моим коллегой, но два ответа не являются точными или информативными.
development_structure.sql - это низкоуровневый дамп схемы, который необходим, когда вы начинаете использовать собственные функции базы данных - либо вы хотите, либо не хотите, вы собираетесь использовать их в какой-то момент.
Что касается вопроса о его хранении или нет, есть некоторые дебаты. Вот информативный пост: http://www.saturnflyer.com/blog/jim/2010/09/14/always-check-in-schema-rb/. И мое взятие на это следует.
Целью development_structure.sql является синхронизация для любой данной фиксации структуры базы данных с кодом без предварительного знания структуры схемы, то есть без необходимости полагаться на ранее существовавшее состояние чтобы получить новый.
Вкратце, имея доступную структуру схемы, всякий раз, когда вы меняете ветвь/фиксацию, вы загружаете ее напрямую и забываете. Это в основном применимо к динамическим и "переполненным" проектам, где разные ветки имеют различия в базовой структуре схемы.
Без сохранения структуры схемы вам всегда нужно использовать существующую ссылочную схему в своей базе данных и перенести ее обратно или переадресовать каждый раз, когда вы меняете ветвь/фиксацию; несколько случаев в реальном мире могут сделать этот процесс неэффективным (например, когда другая ветвь не имеет некоторых миграций, которые у вас есть в настоящее время, или некоторые миграции не могут быть отброшены назад).
Еще одна проблема - автоматизированные сборки, которые страдают от одних и тех же проблем, и что еще хуже, они не могут применять ручные изменения.
Единственным недостатком является то, что для этого требуется определенная привычка, которая заключается в том, чтобы хранить ее каждый раз, когда вы выполняете миграцию. Легко сказать, но и легко забыть.
Я не говорю, что вы не можете жить без development_structure.sql - конечно, можете. Но если у вас есть это, при изменении ветки/фиксации вы просто загружаете и забываете; если вы этого не сделаете, вам [может] придется пройти ряд ручных шагов.
Он создается, когда вы запускаете команду rake, чтобы клонировать вашу базу данных разработки в тестовую базу данных. База данных разработки выводится на SQL, который затем считывается в тестовую БД. Вы можете безопасно удалить его.
В рельсах 3 вам даже не нужно писать эту строку,
config.active_record.schema_format =: sql
Вы можете сгенерировать этот файл structure.sql, просто выполнив вышеупомянутую команду rake, упомянутую выше