@ Xulfee, это довольно широкий вопрос, и многое зависит от характера вашего проекта.Подходы, на которые вы ссылаетесь, влияют на многие аспекты общей архитектуры.Например:
Полностью ли нормализована база данных?
Нормализация базы данных обычно помогает решить проблему сложности вашей концептуальной модели.При правильной (заметьте, я не сказал «полностью») нормализации ваша модель должна быть достаточно простой, и потребители базы данных (разработчики, ваша команда BI, эксперты в области и т. Д.) Должны иметь возможность получить хорошее представление обизнес-проблемы, которые решаются с вашей базой данных.При этом нормализация может привести к довольно большой проблеме отчетности и анализа.При написании запроса для отчета по большой, достаточно нормализованной базе данных вы можете столкнуться с проблемами производительности, присоединив множество таблиц.Введите схемы снежинок .Итак, на ваш вопрос: это зависит.Каковы ваши требования к отчетности?Сколько транзакций в среднем нужно поддерживать?Насколько сложна ваша концептуальная модель?Вы можете разбить базу данных на более мелкие связанные модели, а не на одну большую?
Какой ORM (linq2sql, структура сущностей) подходит для этого проекта?
ОпятьORM - это инструмент.Вы должны спросить себя, какую конкретно работу вы пытаетесь выполнить?Выбор ORM (или даже использование ORM в первую очередь) - это решение, которое я бы порекомендовал вам принять на раннем этапе, поскольку оно может повлиять на все - от производительности до сплоченности команды разработчиков.Есть много отличных вариантов:
Каждая из вышеперечисленных структур выполняет фантастическую работу по абстрагированию вашего уровня персистентности.У каждого есть свои плюсы и минусы - большинство из них сводятся к проблемам инфраструктуры: производительность, конфигурация, совместимость схемы / языка, шаблоны персистентности, поддержка поставщиков.Если бы у меня был выбор, я бы спросил себя, с какой из фреймворков моя команда разработчиков наиболее удобна?Какой из них поддерживает ожидаемый уровень активности системы?С каким поставщиком я готов вбрасывать?Я видел довольно успешные системы, которые используют довольно маленькие ORM (то есть Stackoverflow использует модифицированную версию Linq-To-Sql), а также довольно большие системы отказывают с довольно сложными ORM.
Должен ли я использовать хранимыепроцедуры, функции БД, триггеры и т. д.?
Этот вопрос касается вашего постоянного хранилища и того, как вы им пользуетесь (а также того, насколько сильно вы хотите разозлить своего администратора баз данных :)).Использование sprocs (хранимых процедур) позволяет вашему dba обеспечить безопасность на очень детальном уровне.Кроме того, если используемый вами формат генерирует динамический sql, вы можете извлечь выгоду из способности базы данных кэшировать запросы, сгенерированные с помощью sprocs.Функции DB могут быть двухсторонними.Они предлагают возможность добавить функциональность и интеллект к вашей модели, в то же время позволяя вам получать довольно большой удар по производительности (то есть с табличными UDF).Триггеры имеют свои подводные камни и должны использоваться с осторожностью, но это обсуждение может быть довольно сложным.Суть для меня в этом случае: сколько логики в базе данных вы хотите поддерживать, и насколько важны безопасность и производительность?У вас есть квалифицированный dba (не просто разработчик, который умеет писать запросы, но dba, способный к настройке производительности и моделированию данных)?Насколько велика ваша база данных?Насколько сложны ваши данные?Подумайте обо всех этих и других вопросах при определении того, как вы хотите управлять своими данными.
Итак, вы задаете несколько хороших вопросов.Не путайте инфраструктурные потребности с потребностями реализации.Определитесь со стеком и работайте с ним, не зацикливайтесь на деталях реализации до того момента, когда вы не сможете успешно завершить проект.При правильном уровне абстракции вам, возможно, будет легче опробовать новые и разные технологии, не рискуя общим успехом проекта.И помните: нет ничего плохого в том, чтобы экспериментировать и пробовать новые вещи, просто будьте готовы к изящному провалу и test, test, test!