С чего начать проектирование при использовании O / R-картирования? Объекты или таблицы базы данных?

Question

Я запускаю новое приложение базы данных, и мне интересно, будет ли лучше начать проектирование на объектах (с UML) и соответственно построить схему базы данных, или начать с проектирования базы данных (с ER) и создать объекты соответственно.

Каковы плюсы и минусы любого подхода?

(я не думаю, что это имеет значение, но на всякий случай: я планирую использовать Java и Hibernate)

Answer 1

Зависит от того, разработано ли ваше приложение для удовлетворения потребностей пользователей или для удовлетворения потребностей разработчиков.

Начните с пользовательских историй и получите классы ООП. И ваши пользователи будут любить вас.

В противном случае вы получите приложение, которое превращает пользователей в клерков ввода данных. (У вас будет много компании.)

Answer 2

Преимущества начала работы с базой данных заключаются в том, что вы будете иметь представление о производительности и своих администраторах баз данных.

Преимущества начала со стороны ООП заключаются в том, что у вас будет более чистый дизайн ОО, но ваш ORM может быть неэффективным.

Я считаю, что «черные ящики» ORM слишком ограничивают, поэтому все мои системы кодируются вручную или генерируется и модифицируется код, поэтому мои базы данных, как правило, довольно плотные, а модель ОО чистая. Я твердо верю, что умные люди - решение несоответствия импеданса.

Answer 3

Это зависит от того, где ваши сильные стороны и куда вы хотите пойти.

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

Начните с объектно-ориентированного анализа, а не объектно-ориентированного проектирования. Я не могу особо подчеркнуть разницу между анализом и дизайном. Люди, которые пишут об объектно-ориентированном анализе, некоторые из которых используют UML в качестве инструмента, стараются четко провести это различие. Анализ относится к проблемной области, а дизайн относится к области решения. Они могут легко смешиваться друг с другом, независимо от того, является ли ваш подход объектно-ориентированным или нет.

Если вы проведете хороший OOA-анализ требований вашего проекта, вы, вероятно, сможете сделать разумную работу по построению концептуальной модели данных параллельно и синхронизации этих двух данных друг с другом. Когда вы создаете концептуальную модель данных, я предлагаю вам придерживаться модели, подобной модели ER.

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

Отображение между OOA и ER достаточно просто, чтобы вы могли управлять двумя моделями параллельно. Там могут быть новые инструменты, которые управляют обоими типами моделей для вас. Отображение между ER и RDM обманчиво просто. В простейшем сопоставлении вы превращаете каждую сущность в таблицу, основанную на идентичности сущности, а каждое отношение - в отдельную таблицу, основанную на внешних ключах, которые ссылаются на сущности. Можно и желательно уменьшить количество таблиц, подключив некоторые внешние ключи к таблицам сущностей, но это деталь.

Из OOA вы переходите к OOD для проектирования и OOP для программирования.

От ER для концептуального моделирования данных вы переходите к RDM для логического моделирования данных и к своему специфическому для СУБД диалекту SQL для физического моделирования данных. Определенно, есть инструменты, которые помогут вам в этом, если ваш проект слишком велик для моделирования на бумаге или белой доске.

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

Если вы разрабатываете одну базу данных и несколько приложений одновременно, все становится действительно интересным.

Answer 4

Если вы пишете OO-приложение, то я обнаружил, что сначала следует начать разработку объектов. Я предпочел бы создать хороший ОО-проект, а затем попытаться оптимизировать базу данных, а не строить базу данных, а затем попытаться приспособить объекты к базе данных.

Инструменты ORM дают вам возможность сосредоточить свое внимание на дизайне объекта.

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

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

Answer 5

Это зависит от того, где вы хотите лучшую производительность. Если вы ожидаете, что база данных станет для вас узким местом, начните проектировать ее, чтобы настроить ее на производительность. Если вы используете базу данных только для сохранения состояния нескольких объектов, которые должны быть эффективными в вашем приложении, разработайте их соответствующим образом. Программное обеспечение для O / R-картографирования не настолько надежно (и не скоро наверстает упущенное) при настройке производительности, как хороший компилятор. Вы по-прежнему будете лучше работать над проектированием для повышения производительности (хотя и с более высокой стоимостью разработки).

Answer 6

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

Answer 7

Любой подход может работать, и у каждого есть свои плюсы и минусы. БД-центрированный подход отлично подходит для многих приложений, которые обмениваются данными. Объектно-ориентированный подход отлично подходит для запуска и запуска одного приложения.

Если БД не существует, я бы подумал о создании приложения, не беспокоясь об этом. Возможно, что-то вроде db4objs даст вам постоянство объектов, в котором вы нуждаетесь, пока вы превращаете свое приложение во что-то полезное. Позже, когда новые приложения предназначены для совместного использования данных или когда специальный запрос становится важным, реляционное отображение БД становится более целесообразным. Может быть, вам никогда не понадобится реляционный. Постройте, когда вам это нужно.

Если БД уже существует или требуется разместить ваши данные, я все равно попытался бы отложить реляционную работу как можно дольше и заставить работать объекты и код. Но я бы передумал, если бы увидел, что пишу сложный код, который мог бы быть выполнен с помощью SQL.

Answer 8

Это зависит. Вы занимаетесь объектно-ориентированным программированием или SQL-ориентированным программированием?