Словарь данных или ORM?

Question

Я нахожусь в процессе замены фреймворка для довольно сложного бизнес-веб-приложения. Наше приложение работает на платформе LAMP, и новая среда будет расширением CodeIgniter. В своих исследованиях по разработке структуры я решила изучить ORM, я никогда раньше не работала с ORM, и я хотела знать, если это будет ценным для нашего приложения. Затем я наткнулся на очень интересное сообщение в блоге под названием «Почему я не использую ORM». Этот блог, похоже, подтвердил многие мои опасения по поводу использования ORM, и в нем также было представлено решение, похожее на то, что я уже планировал. .

Под "словарем данных" я планирую использовать это определение из "Программист базы данных" blog:

Термин «словарь данных» используется многими, в том числе и мной, для обозначения отдельного набора таблиц, который описывает таблицы приложений. Словарь данных содержит такую ​​информацию, как имена столбцов, типы и размеры, а также описательную информацию, такую ​​как заголовки, подписи, первичные ключи, внешние ключи и подсказки для пользовательского интерфейса о том, как отображать поле.

Таким образом, при выборе «словаря данных» вместо ORM я могу проявлять тенденцию к подтверждению, независимо от причин, по которым я устал от ORM:

1. Я никогда раньше не пользовался ORM, я мало что знаю об этом.
2. Этот фреймворк нужно построить довольно быстро, у моего босса мало времени, и мне нужно создать работающее приложение, которое позволит плавно перейти на более современный фреймворк.
3. Мой начальник уже думает, что я перерабатывал эту структуру (поверьте мне, я не очень близок к этому) и параноидален по поводу структуры, которая мешает нам делать то, что нам нужно, и создает ошибки, которые мы не может решить в течение необходимого количества времени. Пока я плохо справлялся с ним, убеждая его в том, что изменения - это хорошо, но я не очень эффективный продавец, и хотя другие разработчики могут помочь мне, босс все еще нуждается в большой уверенности.
4. Наш старый фреймворк - процедурный, наш код - PHP, и наши разработчики очень хорошо знают SQL. ORM будет большим изменением.
5. В нашей базе данных есть десятки таблиц, многие из которых содержат сотни тысяч записей на довольно старом сервере. В прошлом мы были сожжены кодом, который повторял опрос базы данных в цикле вместо того, чтобы делать один запрос, чтобы извлечь все необходимые данные одновременно. Избежать этой проблемы с помощью SQL, написанного вручную, довольно просто. Обеспечение того, чтобы это всегда происходило в случае необходимости с ORM, мне неизвестно и кажется рискованным.

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

1. Реализация правил контроля доступа в самих строках таблицы была бы неоценима.
2. Также было бы полезно автоматически сгенерировать изменения базы данных, документацию и проверку схемы.
3. Одним из требований платформы является общая функция истории данных / аудита, которая может применяться к любой подфункции в нашем приложении. Словарь данных или эквивалент по существу требуется для предоставления такой функции. История должна содержать подробную информацию о структуре и типах данных в базе данных.
4. Наши системы содержат широкий спектр типов данных, которые были бы более правильно адресованы, если бы они рассматривались как формальные типы в приложении. Во-первых, фрагменты HTML (которых у нас много в наших данных, они необходимы) должны быть закодированы как сущности в некоторых случаях, декодированы как HTML в других, проанализированы для ссылок и изображений в некоторых случаях и всегда проверены на правильность. Кроме того, существуют даты, измерения, валюта и различные другие поля, которые могли бы получить четкое определение в коде того, как следует манипулировать этими данными.

Идея словаря данных, которую я хотел бы реализовать, была бы последовательностью объектов в отдельных файлах PHP, и было бы много ООП, однако она будет использоваться так, как это очень похоже на концепцию словаря данных, представленную в " Блог программиста ». Это будет единственное исходное определение полной схемы базы данных для всей инфраструктуры.

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

Answer 1

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

Я могу представить (возможно, незаслуженную) апробацию, которая будет связана с ORM, как только запрос будет медленным или начнут появляться проблемы с блокировкой транзакций. Не говоря уже о влиянии на график разработки. Зачем создавать неквалифицированный фактор риска?

Answer 2

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

Позже вы можете пересмотреть. Если это так, то не должно быть проблем с использованием словаря данных и ORM для новых разработок параллельно. Обе технологии не являются взаимоисключающими.

Если вам не нравится идея смешивания различных технологий: придерживайтесь надежного дизайна ООП и четко разделяйте проблемы между логикой домена и доступом к данным, тогда переход на ORM не должен быть таким болезненным или, по крайней мере, возможным. 1005 *

Удачи!

Answer 3

У вас есть фреймворк, который поддерживает создание приложений с использованием «Словаря данных»? Если это так, попробуйте, это может решить ваши проблемы. Если нет, то есть много хороших и работающих ORM-фреймворков, которые имеют большие сообщества, которые приходят с источником (так что вы можете исправлять ошибки самостоятельно, даже если «продавец» отказывается вам помогать).

Если вы хотите быстро взглянуть на хороший веб-фреймворк ORM, я предлагаю Django или TurboGears . Они основаны на Python, который будет хорошим изменением после использования PHP. Я обычно предпочитаю TurboGears, но Django кажется более гладким в данный момент. Оба варианта просты в настройке, и вы сможете создать прототип за день или два. Это даст вам представление о шансах.

PS: я также не думаю, что инструменты ORM - это TEH SOLUT10N. Я использую Hibernate или SQL Alchemy, когда это имеет смысл, но я часто использую свои собственные простые средства отображения.