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

Question

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

К «словаря данных» Я планирую использовать это определение из "The Database Programmer" блога:

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

Таким образом, в выборе «словарь данных» над ОРМОМ I может быть экспонированием предвзятости подтверждения, независимо вот мои причины быть устал от ОРМА:

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

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

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

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

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

Answer 1

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

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

Answer 2

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

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

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

Answer 3

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

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

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

Удачи вам!