Генерация таблиц базы данных из определений объектов

Question

Я знаю, что есть несколько (автоматических) способов создания слоя доступа к данным для управления существующей базой данных (LINQ to SQL, Hibernate и т. Д.). Но я немного устаю (и считаю, что должен быть лучший способ сделать что-то), например:

1. Создание / изменение таблиц в Visio
2. Использование «Обновления базы данных» Visio для создания / изменения базы данных
3. Импорт таблиц в объект «Классы LINQ to SQL»
4. Изменение кода соответственно
5. 1012 * Компиляция *

Как насчет способа генерации схемы базы данных из определения объектов / сущностей? Кажется, я не могу найти хорошие ссылки на подобные инструменты (и я ожидаю, что какая-то встроенная поддержка будет хотя бы в некоторых средах).

Было бы идеально, если бы я мог просто:

1. Изменить определение объекта
2. Изменить код, управляющий объектом
3. Компиляция (изменения в базе данных выполняются автоматически)

Answer 1

Check DataObjects.Net - предназначен для поддержки именно этого случая. Только код и ничего больше. Его слой обновления схемы , пожалуй, самый функциональный из всех, которые вы можете найти, и он действительно полностью абстрагирует SQL для обновления схемы.

Ознакомьтесь с видео продукта - вы не заметите, что ничего не сделано для синхронизации схемы. Пример обновления схемы показывает предполагаемое использование этой функции.

Answer 2

То, что вы описали, это GORM. Он является частью Grails фреймворка и предназначен для работы с Hibernate (возможно, JPA в будущем). Когда я впервые использовал Grails, это казалось задом наперед. Мне было удобнее работать в стиле Rails, создавая таблицы и позволяя инфраструктуре генерировать леса из схемы базы данных. GORM сохраняет ваши доменные объекты для вас, поэтому вы создаете и изменяете объекты, он управляет созданием / обновлением базы данных. Это имеет больше смысла теперь, когда я привык к этому. Извините, что дразню вас, если вы не ищете новую платформу, но она доступна по плану для выпуска 1.1, чтобы сделать GORM автономным.

Answer 3

Когда мы создавали первую версию нашего собственного фреймворка ( Inon Datamanager ), я сделал так, чтобы он считывал уже существующие таблицы SQL и автоматически генерировал из них объекты Java.

Когда мои коллеги, пришедшие из Smalltalkish, создали вторую версию, они начали с объектов и затем автоматически сгенерировали таблицы.

На самом деле, они совсем забыли о SQL-части, пока я не вернулся и не добавил ее. Но в настоящее время мы просто запускаем триггер при запуске приложения, который перебирает объектную модель, проверяет, существуют ли таблицы и все нужные столбцы, и создает их, если нет. Очень удобно.

Это оказалось намного проще, чем вы могли ожидать - если ваш любимый инструмент не поддерживает аналогичный процесс, вы, возможно, могли бы написать его через пару часов - предполагая, что реляционное сопоставление с объектом относительно просто.

Но суть в том, что, похоже, это зависит от того, являетесь ли вы культурным объектом или человеком, работающим в базе данных - вы можете рассматривать любой из них как авторитетный источник.

Answer 4

Как предположил Джейсон, объект БД может быть хорошим выбором. Взгляните на db4objects .

Answer 5

Я считаю, что эту проблему пытается решить Microsofy Entity Framework . Хотя он не предназначен специально для «Компиляции (изменения базы данных выполняются автоматически), он решает проблему обработки изменений в модели предметной области без огромной зависимости от базовой модели данных.

Answer 6

Возможно, вы ищете объектную базу данных .

Answer 7

Вроде поздний ответ, но здесь он идет:

Я столкнулся с точно такой же проблемой и закончил тем, что написал свое собственное решение для нее, работая только с .NET и SQL Server. По сути, он реализует описанный вами процесс:

• Все объекты БД хранятся как встроенные CREATE сценарии как часть исходного кода
• Объекты БД устанавливаются автоматически (или по запросу) при использовании функции доступа к данным
• Все изменения, не связанные с таблицей, также выполняются автоматически (или по запросу) одновременно
• Изменения в таблице, которые могут потребовать особого внимания при переносе данных, выполняются с помощью (созданных вручную) сценариев изменений также при обновлении базы данных
• Даже ручные изменения, сделанные в любом объекте базы данных, могут быть обнаружены, так что целостность схемы может быть проверена и исправлена ​​
• Дополнительный облегченный ORM может отображать хранимые процедуры и объекты, а также наборы результатов (даже несколько)
• Приложение командной строки помогает поддерживать синхронизацию исходных файлов SQL с базой данных разработки

Библиотека, включая базу данных, предоставляется бесплатно по лицензии LGPL.

http://code.google.com/p/bsn-modulestore/

Answer 8

Да, Django работает хорошо.

да, он будет генерировать ваши таблицы SQL из определений модели данных (написанных на python)

Не всегда изменяются существующие таблицы, если вы обновляете свою структуру, возможно, вам придется запустить таблицу ALTER вручную

В Ruby on Rails есть еще более продвинутая версия этих функций (миграция Rails), но мне не очень нравится среда, я нахожу ruby ​​и rails довольно своеобразными

Answer 9

Я продолжал копаться в некоторых "основных" фреймворках, и кажется, что Django делает именно то, о чем я говорил. Или так кажется из этого скринкаста .

У кого-нибудь есть замечания по этому поводу? Это хорошо работает?

Answer 10

Некоторые из действительно больших собак, такие как ERwin Data Modeler , будут возражать против БД. Вы должны иметь большие деньги, чтобы позволить себе продукт.