Заменить реляционную БД (SQL Server) на основе правил / декларативной реализации?
Я начал работать над проектом в сфере финансовых услуг, основанным (главным образом) на SQL Server (2000), ColdFusion (8) и некоторых приложениях Access/.NET. Этот проект начинался как несколько простых форм доступа /VBA и постепенно преобразовывался в веб-интерфейсы.
Я мог бы сказать, что проектирование базы данных и кодирование приложений были сделаны людьми, которые учились на работе и не имели возможности узнать о хороших принципах проектирования с самого начала. Многие из бизнес-правил установлены в множестве каскадных функций и хранимых процедур, а также в шаблонах веб-сервера. В сложных 500-строчных UDF-функциях SQL, использующих некомментированные константы, существует огромное количество особых случаев. Очень трудно отследить все взаимодействия между 10-20 UDF, которые могут быть вовлечены в запрос. Некоторые из запросов выполняются слишком долго (до 15 минут).
Несмотря на то, что таблицы достаточно хорошо проиндексированы, отсутствует связь FK и почти отсутствует ссылочная целостность. БД обновляется нечасто ежедневными пакетами небольшого объема (1000 записей в нескольких таблицах). Она в основном используется в качестве хранилища данных - я полагаю, хранилище данных. Мы получаем очень редкие тупики или задержки.
Итак, мой вопрос: если я хочу повторно реализовать весь проект, включая базу данных и внешний интерфейс, имеет ли смысл взглянуть на нереляционные реализации? Основная БД составляет всего около 1 ГБ (.mdf), поэтому она легко помещается в памяти. Я хотел бы перейти от структуры SQL-запроса к некоторой декларативной модели, которая могла бы эффективно компилироваться и выполняться. При необходимости я мог бы использовать БД SQL просто как хранилище данных.
2 ответа
Почему вы хотите перейти от реляционного подхода? Переходя от реляционного подхода, вы только углубите бизнес-логику в код, используя любой другой подход. Как вы указали, модель данных довольно проста. Вы могли бы сначала взглянуть на улучшение самой модели данных. Причина, по которой они могут не иметь каких-либо ограничений ссылочной целостности, заключается в том, что первоначальные разработчики могли предположить, что это приведет к снижению производительности. Они могут выполнять проверки с использованием кода, который сам по себе может быть неэффективным.
Ваша БД маленькая. добавление ограничений ссылочной целостности никак не повлияет на производительность. При необходимости вы можете переписать некоторые из UDF. Почему вы не используете анализатор запросов для просмотра показателей производительности? Это даст вам хорошую отправную точку для анализа.
- Если я хочу повторно реализовать весь проект, включая базу данных и внешний интерфейс, имеет ли смысл взглянуть на нереляционные реализации?
В целом, большинство разработчиков, даже те, кто дышит картами / сокращениями и носят футболки NoSQL, чувствуют себя намного более комфортно с SQL.
Если ваше приложение следует классической модели MVC/MVP, то большинство фреймворков (например, Spring, Rails, Grails, Django, Webmachine и т. Д.) На самом деле поставляются с поддержкой первого класса для серверной части SQL. И некоторая поддержка для NoSQL.
Если вы не видите никакой реальной выгоды, которую NoSQL может принести вашей системе ( вот преимущества, которые я написал для другого вопроса), зачем беспокоиться?
- Я хотел бы иметь набор "англоязычных" правил, которые описывают преобразования из базовых необработанных данных в форму, которая может напрямую использоваться приложением (веб)
Кажется, вы говорите о классическом постоянном слое с сервисным слоем поверх него. куда "english-language" rules просто "english-language" методы на вашем уровне обслуживания. Если вам не нужен более сложный механизм правил, но в большинстве случаев он не нужен.