Рекомендации по созданию приложений баз данных [дубликаты]

    

У этого вопроса уже есть ответ:

    

Когда-то было обычной практикой для того, чтобы как логика бизнес-логики, так и логика базы данных были написаны на одном языке (например, PL /SQL, Transact SQL и т. д.), в последнее время практика заключается в том, чтобы разделить приложение на слои /таких как база данных, бизнес-логика и презентация, причем каждый уровень написан на другом языке. Как правило, ORM используется для облегчения связи между бизнес-логикой и базой данных.

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

Я нашел эту статью Блахи «Объектно-ориентированный дизайн хранимых процедур базы данных». Существуют ли какие-либо другие книги, документы или примеры баз данных, которые иллюстрируют лучшие практики разработки лучших приложений баз данных?

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

Хорошо ли для бизнес-хранимой процедуры напрямую обращаться к таблице? Или должен ли доступ к таблице через методы CRUD? Есть ли какие-нибудь инструменты для генерации кода? Спасибо.

11 голосов | спросил Antonio2011a 26 AM00000060000003331 2011, 06:46:33

1 ответ


7

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

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

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

ответил Bill Leeper 31 PM00000060000000831 2011, 18:40:08

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132