Заменить реляционную БД (SQL Server) на основе правил / декларативной реализации?

Question

Я начал работать над проектом в сфере финансовых услуг, основанным (главным образом) на SQL Server (2000), ColdFusion (8) и некоторых приложениях Access / .NET.Этот проект начинался как несколько простых форм доступа / VBA и медленно преобразовывался в веб-интерфейсы.

Я мог бы сказать, что проектирование базы данных и кодирование приложений выполнялись людьми, которые учились на работе и не имеливозможность узнать о хороших принципах дизайна с самого начала.Многие из бизнес-правил установлены в множестве каскадных функций и хранимых процедур, а также в шаблонах веб-сервера.В сложных 500-строчных UDF-функциях SQL, использующих некомментированные константы, существует огромное количество особых случаев.Очень трудно отследить все взаимодействия между 10-20 UDF, которые могут быть вовлечены в запрос.Кажется, что некоторые запросы выполняются слишком долго (до 15 минут).

Несмотря на то, что таблицы достаточно хорошо проиндексированы, в них отсутствуют отношения FK и почти отсутствует ссылочная целостность.БД обновляется нечасто ежедневными пакетами небольшого объема (1000 записей в нескольких таблицах). Она в основном используется в качестве хранилища данных - я полагаю, хранилище данных.Мы получаем очень редкие тупики или задержки.

Итак, мой вопрос: если я хочу повторно реализовать весь проект, включая базу данных и внешний интерфейс, имеет ли смысл взглянуть на нереляционные реализации?Основная БД составляет всего около 1 ГБ (.mdf), поэтому она легко помещается в памяти.Я хотел бы перейти от структуры запросов SQL к некоторой декларативной модели, которая могла бы быть эффективно скомпилирована и выполнена.При необходимости я мог бы использовать БД SQL просто как хранилище данных.

Answer 1

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

В целом, большинство разработчиков, даже те, кто дышит картами / сокращениями и носят футболки NoSQL, чувствуют себя намного комфортнее с SQL.

Если ваше приложение следует классической модели MVC / MVP, то большинство фреймворков (например, Spring, Rails, Grails, Django, Webmachine и т. Д.) На самом деле поставляются с поддержкой first class для SQL задний конец. И некоторая поддержка для NoSQL.

Если вы не видите реальной выгоды, которую NoSQL может принести вашей системе ( здесь - это преимущества, которые я отправил на другой вопрос), зачем беспокоиться?

• Я хотел бы иметь набор «англоязычных» правил, которые описывают преобразования из исходных необработанных данных в форму, которая может напрямую использоваться приложением (веб)

Похоже, вы говорите о классическом персистентном слое с сервисным слоем поверх него. Где "english-language" rules - это всего лишь "english-language" методов на вашем уровне обслуживания. Если вам не нужен более сложный механизм правил, но в большинстве случаев он не нужен.

Answer 2

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

Ваша БД мала. добавление ограничений ссылочной целостности никак не повлияет на производительность. При необходимости вы можете переписать некоторые из UDF. Почему вы не используете анализатор запросов для просмотра показателей производительности? Это даст вам хорошую отправную точку для анализа.