Сопоставление устаревшей базы данных MySQL с хорошей .NET ORM для миграции системы

Это довольно длинный вопрос, но я буду очень признателен за ваши мысли и предложения.

Мы заняты восстановлением устаревшей системы, написанной на PHP и MySQL, и заменой ее компонентов на ASP.MVC на C # и SQL Server. Унаследованная архитектура оставляет желать лучшего, и существует серьезная проблема со спагетти-кодом, отсутствием ссылочной целостности в БД, неиспользуемым кодом и полями базы данных и просто плохим кодированием в целом.

Как бы мне ни хотелось, мы не можем просто вырвать весь старый код и заменить его. Компания должна оставаться работоспособной в процессе разработки, поэтому нам нужно будет создавать новые функции, используя старые базы данных, чтобы их данные всегда были точными. Уровень точности данных не в реальном времени, но если бы у нас было 2 системы, они должны были бы синхронизироваться в 100% случаев. Старая система использует 6 разных баз данных MySQL, все на одном сервере под управлением Linux. Мы будем использовать Windows 2008 R2 на новом сервере для новой системы, и мы планируем использовать последнюю версию SQL Server.

Проблема, которую я должен решить, заключается в следующем: мне нужно каким-то образом отобразить все эти базы данных в консолидированную модель, которую мы можем использовать с помощью C # для разработки новой системы. После того, как мы переместили все функции на C #, нам нужно перенести данные в базу данных, которая соответствует нашей модели кода. Эта БД будет работать на SQL Server. Я пока не слишком беспокоюсь о миграции; Моя текущая проблема - найти инструмент ORM, который позволит мне сопоставить эти 6 баз данных MySQL в единую, хорошо спланированную и спроектированную модель, которую мы можем использовать для новой разработки.

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

Возможно ли то, что я пытаюсь сделать? Это жизнеспособно с точки зрения усилий? Есть ли ORM, который может все это сделать? и как еще можно сохранить работоспособность компании при активном развитии системы?

Я просмотрел эти варианты ORM:

  • SubSonic (отличный, но я думаю, слишком легкий для того, что мы пытаемся)
  • Entity Framework (похоже, я смогу использовать это, если буду использовать очень грязные модели с множеством хранимых процедур для вставок, обновлений и удалений)
  • NHibernate (клиент не хочет, чтобы мы использовали это из-за плохого опыта в прошлом)
  • LLBLGen (похоже, что он может делать то, что нам нужно, но долгосрочная поддержка может быть проблемой для клиента)

На что еще я должен посмотреть? Могу ли я попробовать другой подход?


.net migration c# data-migration orm
person Johann    schedule 29.02.2012    source источник
comment
Есть ли причина, по которой вы не можете просто спроектировать новую базу данных, перенести / создать данные для тестирования и разработать с учетом новых баз данных? Затем, когда вы будете готовы к переключению, вы можете сразу перенести весь контент и переключиться на новые приложения. Это должно быть проще, чем полагаться на ORM для отключения уровня устойчивости в последнюю минуту, и позволит вам развиваться на основе хорошо реализованной чистой модели и базы данных.   -  person sga101    schedule 29.02.2012
comment
Привет @ sga101, нам нужно повысить ценность для бизнеса в процессе разработки, и мы хотели бы предоставить клиенту новые функции и этапы в новом пользовательском интерфейсе по мере разработки. К сожалению, мы не можем закончить разработку и переключиться за один раз, так как слишком высок риск сбоя операций.   -  person Johann    schedule 29.02.2012

Ответы (2)


arrow_upward
0
arrow_downward

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

NHibernate - простой выбор. LLBLGen был бы моим вторым выбором. Я бы даже не стал беспокоиться о EF или SubSonic, поскольку они очень бедны по функциям по сравнению с двумя другими, и вам нужна достойная поддержка функций в вашем сценарии.

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

person Michael Maddox    schedule 29.02.2012

arrow_upward
0
arrow_downward

Для Entity Framework: если вы готовы поддерживать один полный набор хранимых процедур со статическим интерфейсом (то есть с той же подписью), вы можете реализовать их все в Transact-SQL в поле SQL Server со связанными серверами (к ферме MySQL). .

Когда придет время, вы сможете перенести данные в SQL Server и обновить свои хранимые процедуры.

По сути, создайте красивую модель с хорошими хранимыми процедурами и в качестве временного решения реализуйте любые уродства внутри хранимых процедур. Когда MySQL исчезнет, ​​вы можете заменить хранимые процедуры на более совершенные.

SQL Server имеет тенденцию извлекать всю удаленную таблицу, когда вы выполняете запросы к связанному серверу, поэтому, если производительность вызывает беспокойство, это может привести к тому, что все ваши хранимые процедуры являются оболочками вокруг _ 1_ (см. Пример A для выполнения запроса на удаленном сервере).

person ta.speot.is    schedule 29.02.2012