Что на первом месте: логика базы данных или приложения?

Question

Каков наилучший способ или рекомендуемая лучшая практика в потоке веб-приложения asp.net на основе базы данных?Я имею в виду сначала базу данных или сначала кодируем или рядом?

Answer 1

Ваш код доступа к данным не будет скомпилирован без существующей базы данных - если вы не заглушите (или не зафиксируете) его. Так что, вероятно, база данных на первом месте.

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

редактировать

Стефани делает чрезвычайно важное замечание:

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

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

Итак, потребуются новые таблицы, а некоторые существующие таблицы устареют. Будут столбцы, которые нужно добавить, столбцы, которые нужно изменить, столбцы, которые нужно отбросить. Вот почему Природа дала нам утверждение ALTER TABLE.

Я не предлагаю, чтобы мы не проектировали наши столы и не собирали их по частям. Я просто предлагаю, чтобы, когда мы начинаем проектировать подсистему HR, нам нужно было позаботиться о таблице EMPLOYEES и таблице SALARIES. Нам не нужно заниматься ИНВЕНТАРЯМИ или ЗАКАЗАМИ, пока мы не начнем работу по продажам.

Answer 2

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

Answer 3

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

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

Это общая точка зрения людей, ориентированных на приложения (они), по сравнению с людьми, ориентированными на базу данных (Мы).Они видят весь смысл упражнения, чтобы «предоставить функции».Это то, что клиенты знают, что они хотят, и просят их.Для них база данных - это просто постоянство, необходимое для этих функций.И когда они готовы, вот и все, функции доставлены, базы данных достаточно для этих функций.Может быть весь Rube Goldberg внутри базы данных с избыточными данными, серьезными нарушениями нормальных форм, ограничениями, навязанными приложением, и что с вами.*

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

Специалисты, ориентированные на данные, не смотрят на систему как на место, предоставляющее только то, что было заданодля, но хранилище Интеллектуального капитала, которое может быть использовано больше, чем какой-либо Application-du-jour.Я не могу начать описывать количество случаев, когда одна команда использовала базу данных приложения какой-либо другой команды для повышения ценности своих приложений.Достаточно взглянуть на все медицинские исследования, которые представляют собой не что иное, как метаанализ существующих исследований.Все это невозможно, если вы считаете, что важны только функции вашего приложения и последующее использование данных ваших приложений.

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

Answer 4

Проделав это довольно много раз, я обнаружил, что неизменно делаю это так:

1. Определите проблему, которую я пытаюсь решить.
2. Запишите несколько вариантов использования.
3. Пусть мой значимый друг или друг скажет мне, если это вообще проблема.
4. Нарисуйте несколько примеров экранов.
5. Написание блок-схем для вариантов использования.
6. Задайте мои вопросы о резиновой утке .
7. Используйте вопросы, чтобы уточнить 1-6.
8. Выпишите «существительные». Те становятся моими моделями данных.
9. Выпишите действия. Это становится логикой приложения.
10. Код данных модели.
11. Код приложения логика.
12. Поймите, что я немного ошибся.
13. Повторите 10-12 раз столько раз, сколько необходимо.
14. Спросите: «Решил ли я проблему»?
15. Если нет, промойте, вспените и повторите 1-15.

Answer 5

Вы, вероятно, в конечном итоге сделаете это "бок о бок".

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

Сначала проведите моделирование, а затем постройте минимум, который вы можете использовать для одной или двух функций. Затем, когда они заработают, добавьте следующую функцию и т. Д.

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

Answer 6

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

Тогда не имеет значения, что реализовать в первую очередь.

Answer 7

Полагаю, вам нужно сначала определить модель данных, а затем - кодирование. Вы должны все тщательно спланировать, прежде чем писать код.

Answer 8

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

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

Например, в самой базовой программе поддержки есть люди и билеты. Люди должны создавать билеты, обновлять билеты и закрывать билеты. Существительные, требующие постоянного хранения, будут входить в вашу базу данных, а существительные + действия будут содержаться в вашем приложении.

Иногда ваши сопоставления таблиц и взаимосвязь между таблицами будут очевидны (люди IE создают заявки, ticket.creatorID = people.personID), а в других случаях взаимосвязь действительно не приходит вам в голову, пока вы не начнете работать с вариантами использования до тех пор, пока вы не начнете писать свой код (IE разные люди имеют разные уровни доступа, определяющие, что они могут делать. На первый взгляд, это выглядит как простое поле в таблице, но на практике это лучше, как отдельная таблица).