Поменять базы данных?

Question

Кажется, что цель многих инструментов ORM и пользовательских слоев доступа к данным (шаблон DAO и т. Д.) Состоит в том, чтобы абстрагировать базу данных до такой степени, что вы могли бы предположительно заменить всю систему базы данных с минимальными затратами. *

Следование общим шаблонам DAL обычно является хорошей идеей в коде, но кажется, что свопирование базы данных никогда не будет минимальной работой. (Стоимость, обучение, перенос данных и т. Д.)

Есть ли у кого-нибудь опыт замены одной базы данных на другую в большой системе и решения проблем, связанных с кодом? Стоит ли беспокоиться об абстрагировании реальной базы данных от вашего кода?

Answer 1

Вопрос 1: Есть ли у кого-нибудь опыт работы с обменять одну базу данных на другую в большой системе, и имея дело с последствия в коде?

Да, мы попробовали это. Наш клиент использует большое клиентско-серверное приложение на базе MS Access. Примерно через пять лет мы рассматривали возможность перехода на SQL Server. Мы проанализировали проблему и пришли к выводу, что обмен базой данных будет очень дорогостоящим и даст лишь несколько преимуществ. Клиент решил не менять местами базу данных. Приложение по-прежнему работает нормально, а клиент по-прежнему доволен.

Обратите внимание, что:

• MS Access используется только для хранения данных и генерации отчетов.
• Серверное приложение обеспечивает доступ к MS Access только на сервере. Обычные многопользовательские приложения MS Access передают большие куски базы данных Access по сети, что приводит к медленной и ненадежной работе базы данных. Это не тот случай для этого приложения. Клиент <> Сервер <> MS Access. Только серверное приложение связывается с базой данных MS Access. На самом деле Сервер имеет эксклюзивный доступ к базе данных MS Access. Ни один другой компьютер не может открыть базу данных MS Access. Вывод: MS Access используется как настоящая СУБД, реляционная система управления базами данных - пожалуйста, не обращайте внимания на то, что MS Access является неполноценным и нестабильным - он работает нормально уже более 10 лет.

Наиболее важные вопросы, которые вам придется рассмотреть:

1. Операторы SQL : (SELECT, UPDATE, DELETE, INSERT, CREATE TABLE) и убедитесь, что они будут совместимы с базой данных SQL. Удивительно, насколько сильно все СУБД отличаются друг от друга (форматы даты, числовые форматы, форматы поиска, строковые форматы, синтаксис объединения, синтаксис создания таблиц, хранимые процедуры, пользовательские функции, (авто) первичные ключи и т. Д.)
2. Генерация отчета : В зависимости от вашей базы данных вы можете использовать другой инструмент отчетности. Наш клиент имеет более 200 сложных отчетов. Преобразование всех этих отчетов занимает очень много времени.
3. Производительность : все СУБД имеют разные характеристики в разных средах. Обычно оптимизация производительности очень сильно зависит от СУБД.
4. Расходы : стоимость инструментов, разработчиков, серверных и пользовательских лицензий сильно варьируется. Он варьируется от бесплатного до очень дорогого. Бесплатно не значит дешево, а дорого не всегда значит хорошо. Необходимо сравнить стоимость / стоимость.
5. Опыт : для наилучшего использования вашей СУБД необходим опыт. Если вам придется разрабатывать «неизвестные» СУБД, ваша производительность пострадает.

Вопрос 2: Стоит ли беспокоиться абстрагирование фактической базы данных от твой код?

Да. В идеальном мире замена базы данных будет просто корректировать строку подключения к данным. В реальном мире это невозможно, потому что все базы данных разные. Все они имеют таблицы и поддержку SQL, но различия заключаются в деталях. Если вы можете сохранить различия в базах данных, защищенных абстракцией - пожалуйста, сделайте это. Составьте список баз данных, которые вам нужно поддерживать. Проверьте выбранные системы баз данных на различия. Предоставить централизованный код для обработки различий. Поддержка одной РСУБД и обеспечение заглушек для будущей поддержки других РСУБД.

Answer 2

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

Однако я все равно использовал бы ORM, поскольку он абстрагирует детали доступа к данным. Разве это не цель объектно-ориентированного программирования? Держите свои проблемы отдельно.

Answer 3

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

Я работал на работах, где мы начали использовать MySQL по денежным соображениям (например, стартап) и, одна из которых мы начали зарабатывать деньги, хотели перейти на Oracle. Мы не сделали этого, но было приятно иметь возможность.

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

Answer 4

Единственный раз, когда я видел переключение базы данных, было с HSQL во время ранней разработки на Oracle, когда проект прогрессировал. ORM сделал это легко.

Я часто использую шаблон DAO для замены служб данных (из базы данных в веб-службу или для замены веб-службы на тестовую заглушку).

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

Если кто-то умно напишет ORM, который обрабатывает кэширование, обновляет только измененные поля, групповые обновления и т. Д. Мне не нужно. Хотя в тех случаях, когда мне нужно что-то особенное, я все равно могу вернуться к SQL, если захочу.