Какой ORM лучше всего использовать с новым приложением Rails 3 против устаревшей базы данных MySQL 5.1? Я не ожидаю, что когда-либо буду выполнять миграцию для этой базы данных (хотя схема может время от времени меняться), но я определенно буду писать в нее.
Rails 3: ActiveRecord против DataMapper (против ???) для устаревших баз данных MySQL
comment
Не могли бы вы поделиться небольшой схемой?
- person rwilliams schedule 14.11.2010
comment
Извините, это интеллектуальная собственность клиента, поэтому я не могу ею поделиться.
- person Mark Richman schedule 14.11.2010
Ответы (2)
Я могу предвзято относиться к DataMapper, но я думаю, что DM в целом является хорошим вариантом для интеграции с устаревшими базами данных.
DM позволяет сопоставлять осмысленные имена моделей и свойств с загадочными устаревшими соглашениями об именах таблиц и столбцов. Это позволяет вам делать это либо для каждой модели/свойства, либо для всего приложения.
DM поддерживает ленивые свойства, которые будут извлекаться только при фактическом доступе.
DM имеет бесшовную поддержку составных первичных ключей.
DM заботятся только о свойствах (столбцах), которые вы явно объявляете в своих моделях. Другие столбцы никогда не будут затронуты или прочитаны.
DM хорошо работает с ограничениями внешнего ключа в вашей базе данных и с помощью dm-constraints. он также поддерживает их создание.
Также есть некоторая документация на http://datamapper.org/docs/legacy.
person
snusnu
schedule
14.11.2010
Существует также библиотека dm-types-legacy (https://github.com/postmodern/dm-types-legacy), которая предоставляет общие типы DM для отображения данных в странном формате (числовые IP-адреса, закодированный текст HTML/URI, даты и т. д.). /строки времени).
person
postmodern
schedule
14.11.2010
Что-нибудь из этого работает с datetime_select? Например, я пытаюсь обновить поле даты и времени, и это не удается из-за этого: publish_at(1i)=›2010, publish_at(2i)=›11, publish_at(3i)=›14, publish_at(4i)=›07, publish_at(5i)=›59
- person Mark Richman; 16.11.2010
