Агностик языка [закрытый] API
Чтобы ответить на ваш вопрос: вы теряете имена столбцов, потому что вы создаете простой набор данных, строку. Это делается вашими скобками. Без них вы должны получить ожидаемый результат.
Но ваше решение не очень удачное: вам следует избегать вычисления ваших отдельных столбцов в каждом отдельном подзапросе. Это можно легко сделать за один SELECT:
select
pe.id,
pe.login,
MIN(pa.value) FILTER (WHERE pa.name = 'nom') as nom,
MIN(pa.value) FILTER (WHERE pa.name = 'prenom') as prenom
from
personnes pe
join pattributs pa ON pe.id = pa.persid AND pe.id = 66
where pa.name = 'nom' or pa.name = 'prenom'
group by pe.id, pe.login
Сначала вам понадобится JOIN, чтобы собрать правильные наборы данных обеих таблиц вместе. Вы должны присоединиться к id.
Тогда у вас есть проблема в том, что у вас есть две строки для имени (которое кажется не очень хорошо продуманным, почему не два столбца?). Эти два значения могут быть сгруппированы по id. Теперь вы можете объединить их.
Что я делаю, так это «объединяю» их (не важно, какую функцию я использую, потому что это должно быть только одно значение). Предложение FILTER отфильтровывает правильное значение.
3 ответа
Я использовал бы API REST, подобный способу, которым работает API Flickr: http://flickr.com/services/api/
Довольно просто создать и поддержать, самые большие оборотные стороны - то, что требуется много документации (но в значительной степени любой способ, которым Вы делаете API, будет иметь эту проблему), и что устойчивая обработка ошибок - необходимость.
Но по-моему, это - лучший способ создать API, который является самым близким к кросс-платформенному / межъязыковой.
Больше информации здесь: http://www.xfront.com/REST-Web-Services.html
Обновление: submitter добавил следующее к сообщению:
Я не настроен против создания его прямой веб-сервис, затем выделяющий файл WSDL. Но что, если я хочу, чтобы клиент API сделал некоторую логику, шифрование, проверку ошибок или так на?
Мне лично не нравится использовать SOAP (использующий WSDL). Существует много свойственных издержек к использованию SOAP, и на сервере и на клиенте. Я думаю именно поэтому, что Вы видите, что все больше общедоступного API записано использование REST. Это действительно понижает барьер для доступа к наименьшему общему знаменателю, позволяя что-либо, что может использовать основной HTTP (ДОБЕРИТЕСЬ и POST (также ПОМЕЩЕННЫЙ, и УДАЛИТЕ для "надлежащего" способа сделать его)) использовать API.
Еще некоторые примеры записанного использования общедоступного API REST: Твиттер, vimeo, Google
До ожидания клиента, который использует Ваш API, чтобы сделать что-либо, Вы не можете! Нет ничего, что Вы сможете сделать, чтобы гарантировать, что потребитель API сделает что угодно правильно. Вот почему устойчивая обработка ошибок так важна. Необходимо проверить и проверить дважды любого и все, что прибывает от клиента. Необходимо всегда с подозрением относиться к этому и даже предполагать, что это злонамеренно. Действительно нет никакого хорошего пути вокруг того факта.
Обновление 2: submitter добавил следующее к сообщению:
Моя исходная идея состояла в том, чтобы создать DLL или блок в.NET, затем клиент выполняет вызовы в этот код, который выполняет сторону клиента. Этот код может говорить по любому коммуникационному протоколу назад к серверу, но мой API работал бы на их поле. Я предполагаю, что REST действительно не выполняет это. Это походит в REST, все - все еще сообщение HTTP. Это - почти веб-сервисы с мылом.
Можно, конечно, сделать это, но это только собирается работать на языки.NET, означая, что межплатформенные и межъязыковые преимущества из окна. И тем не менее, в конце, Вы действительно предотвращаете что-нибудь? Разработчик собирается или использовать Ваш удаленный API, или Ваш локальный DLL или блок. Так или иначе он оказывается перед необходимостью знать, как использовать его и использовать его право, иначе Вы собираетесь бросить ошибку. Все, что Вы действительно делаете, изменяется, откуда ошибки брошены. Который может быть важен для Вас (если так, упомяните, почему), но действительно ничего не изменяет в уравнении.
Но Вы несколько корректны в высказывании, что REST похож на довольно веб-сервисы без SOAP. Технически REST является веб-сервисами также, его просто, что веб-сервисы прибыли для общего значения SOAP. Это действительно - другой способ достигнуть того же самого. Самые большие различия - то, хотя это, требуется больше программирования и мысли о Вашей стороне (и потенциально больше программирования на стороне клиента), но Вы обмениваете это на устойчивость, меньше служебное и в потребителе и в сервере и самой широкой аудитории для API. Это действительно - наименьший общий знаменатель.
Я - первые годы на веб-сервисах, но я думаю, что один из ключевых пунктов то, что много инструментов поддержек реализация клиентов на основе описания сервиса как WDSL.
Я не поставил клиентского программного обеспечения ни с чем, что я сделал, я ожидаю, что любой пользователь сможет создать их собственные клиенты, подходящие для их потребностей.
Если Вы проверяете API flickr, как предложено одним из Ваших других ответов, я не думаю, что они предоставляют клиентский код, другие люди создали и внесли клиентский материал.
Простой ответ, нет.
Сложный ответ: создайте API и скомпилируйте его в COM dll. Затем просто создайте код обертки для языков, которые не могут обработать это.
Простой ответ № 2, сделайте исходный сервис столь же тривиальным, или так же универсально приемлемым, относительно не требуют API (я обычно реализовывал это посредством опроса базы данных серверной стороны. Ужасный, но любой язык, который может получить доступ к базе данных, может использовать программу).