LINUX.ORG.RU

Доступ к СУБД через API


0

1

Доброго времени суток. Есть тут такой вопрос. Хотел бы спросить у сообщества. Как Вы думаете, целесообразно ли осуществлять доступ к СУБД(Informix, PostgreSQL и т.д.) через прослойку API. Т.е. на хосте где с СУБД, крутится сервер который общается с СУБД, и принимает соединения от клиентов. А на стороне клиентов работает API(обертка на SQL) запросы которого идут к серверу. Грубая схема тут(нарисована за минуту, так что не пинайте)http://sergeserver.dyndns.org/files/cs.png Или же лучше напрямую общаться клиентам с СУБД. Интересует, есть ли уже реальные реализации, которые работают, примеры.



Последнее исправление: Tuki (всего исправлений: 1)

есть какая-то причина так делать? ведь проще написать прослойку, которая на стороне клиента будет преобразовывать вызовы в SQL и общаться сразу с удаленным сервером СУБД, а не своим

aho
()
Ответ на: комментарий от aho

Согласен, можно и опустить на стороне сервера СУБД свой сервер. Но вопрос тот же. смысл в прослойке этой ? аргументы:

1. То что скрываем структуры СУБД от пользователя(сомнительно, как мне кажется)

2. Не надо при изменении структуры БД, менять софт клиентов, а достаточно только править API.

Tuki
() автор топика

Целесообразно, если в дальнейшем планируются различные виды клиентов: нативное приложение, интернет-сайт и т. д.

reader
()
Ответ на: комментарий от reader

А падение производительности ? А смысл делать обертку например к postgis ? Как я понимаю увеличится время на разработку приложений, ведь придется ждать пока реализуется API, отладка и т.д.

Tuki
() автор топика

Это называется трёхзвенкой. Только API это не API доступа к СУБД, а API самого приложения. Просто обёртывание SQL в API это почти что ORM, тут как бы промежуточный сервер не нужен.

mashina ★★★★★
()
Ответ на: комментарий от Tuki

А не затруднит ли при такой реализации отладку комплекса в челом ?

Tuki
() автор топика
Ответ на: комментарий от Tuki

Да, оно. Ещё один паттерн с нормальными СУБД это реализация логики СУБД в хранимых процедурах (постгрес это умеет делать хорошо), а из клиента нужно будет только вызывать хранимки, т.е. совсем простенькая обёртка.

mashina ★★★★★
()
Ответ на: комментарий от mashina

Видимо еще кое что нужно добавить. Реализуется это API так. Есть СУБД с набором таблиц, которые как я понимаю устаканены. и уже под эти таблицы(ТОЛЬКО) написано API. Это нормально ?

Tuki
() автор топика

Извините, но ощущение такой, буд-то вы из криокамеры :) Ладно, не буду издеваться, вот неплохая ссылка: http://habrahabr.ru/blogs/refactoring/65432/

Хотя если вам нужен не БЛ-слой, а именно прослойка между sql, то смотрите на DBSLayer.

dizza ★★★★★
()
Ответ на: комментарий от mashina

Ещё один паттерн с нормальными СУБД это реализация логики СУБД в хранимых процедурах

А я такой подход порицаю :)

dizza ★★★★★
()
Ответ на: комментарий от dizza

Вы бы написали кто :) Ну я так понял, что это я. Прочитаю статью, а потом задам вопросы

Tuki
() автор топика
Ответ на: комментарий от dizza

А я такой подход порицаю :)

А кого это волнует? :)

mashina ★★★★★
()
Ответ на: комментарий от Tuki

Я не совсем понял, что вы хотели сказать, но похоже на ODBC со товарищи, JDBC и т.п. Или ORM, если более высокого уровня.

Есть СУБД с набором таблиц, которые как я понимаю устаканены. и уже под эти таблицы(ТОЛЬКО) написано API. Это нормально ?


Это уже дело разработчика приложения и зависит от его потребностей. Как может под частный случай (фактически, под ваше конкретное приложение) быть уже готовая реализация?

proud_anon ★★★★★
()
Ответ на: комментарий от mashina

Только всем известно, что хранимые процедуры райт -онли. И если надо поправитть, то проще написать заново

anonymous
()
Ответ на: комментарий от anonymous

Давайте не будем выдавать свои фантазии за «всем известно». Всё зависит от конкретного случая и нечего устраивать флейм на эту тему.

mashina ★★★★★
()

Да, уже есть реальные реализации.

Наименее распространённые вариант - это веб-сервер, работающий рядом с SQL-сервером. Клиенты обращаются к веб-серверу при помощи «обёртки» - протокола HTTP.

Sorcerer ★★★★★
()

ТС напиши мне в жаббер, есть у меня одна хитрая штука.

JID mikedm сцабако jabber.ru

MikeDM ★★★★★
()
Ответ на: комментарий от mashina

Запихивать логику в сторед процедуры - это каменный век, так делали 20 лет назад

aldayneko
()

>>Как Вы думаете, целесообразно ли осуществлять доступ к СУБД(Informix, PostgreSQL и т.д.) через прослойку API.

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

aldayneko
()
Ответ на: комментарий от aldayneko

1. А если вздумается поменять СУБД ?

а если не вздумается?

2. А если логика очень сложная ?

а если не очень сложная?

хорошо поговорили, да?

mashina ★★★★★
()
Ответ на: комментарий от mashina

> а если не очень сложная?

То проект либо будет закрыт, либо логика станет очень сложной.

Всегда ваш, К.О.

LamerOk ★★★★★
()
Ответ на: комментарий от LamerOk

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

dizza ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.