Базы данных с открытым доступом

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

По-моему было бы вполне логично предоставлять доступ к публичным данным напрямую, а не посредством HTTP, XML и прочей мути.

Потому что это не сможет защитить чьи-то данные от чего-нить типа:

UPDATE table set column="ololo" //без WHERE

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

Потому что это не сможет защитить чьи-то данные от чего-нить типа

Дать прав только на SELECT-ы

неэффективные запросы со стороны глупых клиентов нагрузят базу и она ляжет

Установить лимит на время выполнения запроса. Ну или можно предварительный анализ запроса делать...

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

Ну будут тысячи разрозненных мусорных БД, которые хрен сведешь в одну. NIH-синдром никто не отменял.

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

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

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

Почитал комментарии и сложилось впечатление, что ТСа почти никто не понял. Я понимаю как добавить ЛОРу кроме фейса еще и доступ к базе и чтобы каждый мог себе свой лор с блэкджеком и дамами намутить.

но черт с ним, с лором.

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

хотя это все утопия. никто не станет вкладывать инфу в общую базу. и будет\будут полупустая база к которой будут обращаться в самых крайних случаях.

ПО мне так ajax и всякие user API и есть то о чём мы говорим.

хотя это все утопия. никто не станет вкладывать инфу в общую базу

Что-то вроде телефонных справочников по госорганизациям - вполне могли бы выкладывать. Я сам такой справочник готов наваять, был даже прототип с фотографиями различных госучреждений (а их, оказывается, совсем не мало) в городе Московский (ныне часть Новой Москвы.)
Да вон банальное расписание электричек: зачем мне груда какого-то неведомого хлама в HTML-виде, если это простейшим набором таблиц можно из базы получить и представить в любом удобном мне виде, хоть в «фортунки» запихать в ASCII-псевдографике.

Ну будут тысячи разрозненных мусорных БД, которые хрен сведешь в одну

Ну так и нужно выделить инфраструктуру «авторитативных» источников данных. В таком случае к недоверенному источнику данных никто просто не обратится, а если и обратится, то огребёт по башке от минкомсвязи.

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

Ведь как было бы здорово, если бы каждый информационный сайт имел если не открытый доступ к своей БД, то хотя бы plain text версию с чётким интерфейсом а-ля sysfs, где каждый файл содержал бы только одно значение в известном формате — будь то температура, давление, ближайшая электричка или курс доллара.

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

Короче, жаль что победил вебдваноль, а не юниксвэй.

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

Практика показывает, что никто за такое не платит.

Поэтому особо добрые ресурсы просто выкладывают время от времени дампы своих БД, а более злые стараются по максимуму защититься от парсинга.

Так это новый инет нужно строить. И сверху вниз. А веб вырос снизу вверх, отсюда и такое разнообразие источников и отсутствие репутации по-дефолту. То есть по-минимуму нужен новый nntp, а по-максимуму некий Всеинтернетовский Госплан. Ни первого, ни второго не предвидится.

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

Семантическая паутина(например микроформаты) развивается и api есть у многих сайтов. А в предложенном варианте с плейн текстом оверхед будет слишком большой.

Инфраструктура особая не нужна, достаточно нормального organization validation ssl сертификата. А насчет того, чтобы не обращались к недостаточно авторитетным источникам данным, то это надо к ЕР идти деньги просить, чтобы цензуру ввести.

Так есть ли публичные общедоступные базы или хотя бы коммерческие проекты подобного рода?

Кастани макскома да поинтересуйся, по каким надуманным причинам он не открыл доступ к базе. И почему не собирается эту роковую ошибку исправлять. :)

было бы вполне логично предоставлять доступ к публичным данным напрямую

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

Разработчики SQL вначале на это и рассчитывали: умные люди считают кто-то сколько потратил и кому сколько нужно начислить ЗП через прямой доступ к БД. И они также сильно удивились, что в нынешнем виде все это зарыто по самые уши.

Проблемы:

1. Тяжеловесные запросы - думаю вопрос решабелен через умную систему вырубания таких запросов самой БД. Типа OOMkiller.
2. Неправомерный доступ через update, delete. Это не проблема. Проблема в лени настраивать всем корректные права доступа. Как никак можно всегда воспользоваться шаблоном.
3. «Лишняя» информация. Есть view'шки, см. п.2.

Итого: проблема надуманная. Те, кто работает с большими БД за деньги скинут дампы. А если давать всем налево и направо кушать не на что будет.

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

А веб вырос снизу вверх, отсюда и такое разнообразие источников и отсутствие репутации по-дефолту.

NTP, DNS, инфраструктура x509 тоже выросли в интернетах без госплана. И тем не менее они есть.

либо подписка стоит денег. И немалых.

Даже информация по VendorID/DeviceID от PCI SIG стоила денег. Ну и что? Я лично не против денег, я против 100000 интерфейсов, ни один из которых не предоставляет корректные данные.

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

Полный доступ к базе никому не нужен. Вообще. Плюс есть ещё операции модификации БД, которые обязательно оборачивать в API. А выборки при этом - только малая часть всех запросов.

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

Короче, жаль что победил вебдваноль, а не юниксвэй.

Полностью согласен, именно об этом и речь. Людям нужна информация, а не Web 2.0. Людям нужны данные, а не HTML. Можно данные засунуть в HTML, но это будет лишь один из великого множества вариантов их представления.

А выборки при этом - только малая часть всех запросов.

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

Вы когда заходите в телефонную будку и листаете справочник, сразу же тянетесь его «модифицировать»???

Нет, не тянусь. А что?

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

Вы бы хотели жить в мире, где база DNS отдаётся только вместе с баннерной рекламой, по сотне мегабайт на каждый 5-ти байтовый запрос?

И это должен быть не пространный теговый высер каких-то очередных индейских Томокошек, а просто данные, как они есть.

Даже для просто данных нужен формат их передачи. В идеале - «самодокументированный» и универсальный, т.е. опять же либо без тегов, либо без служебных запросов не обойтись. И если данные не маленькие, то сразу встанет вопрос об асинхронности - не?

В идеале - «самодокументированный» и универсальный

См. x500. Всё украдено до нас, не правда ли? Интересно, что для LDAP новые атрибуты каждый конечно может придумывать сам сколько угодно, но для того, чтобы их могли использовать все, требуется регистрация в IANA. Сравните, например, с полной анархией в мире SQL баз данных.

Дать прав только на SELECT-ы

SELECT * FROM table ORDER BY no_index_field положит любую достаточно большую СУБД. С индексом получше, но всё равно положит. А если у тебя обёртка, то можно статичным HTML всех кормить, ибо запросы на 146% одни и те же.

Установить лимит на время выполнения запроса. Ну или можно предварительный анализ запроса делать...

ну дык вот его и делают.

Так и пусть выполняют такой запрос, но будут готовы к тому, что ответ вернётся через 5 лет. Квоты в данном случае решают: кто-то со свои 0.001% загрузки процессора быстро получит нужные данные, а кто-то сделает запрос на несколько лет исполнения, который автоматически отрубится по таймауту через день после его инициации. Это же просто политика: на техническом уровне подобные «проблемы» легко решаются, остаётся только довести до сведения клиента информацию о существующей политике запросов к СУБД.

Понятно, что тут возникает проблема с монетизацией, ибо рекламу совать некуда.

ну почему «некуда»? Вот гугл суёт же первыми результатами проплаченные запросы. Тоже можно так сделать.

2. Неправомерный доступ через update, delete. Это не проблема. Проблема в лени настраивать всем корректные права доступа. Как никак можно всегда воспользоваться шаблоном.

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

3. «Лишняя» информация. Есть view'шки, см. п.2.

view'шки таки тоже ресурсы жрут, не?

Это же просто политика: на техническом уровне подобные «проблемы» легко решаются

я-бы не сказал, что настолько «легко».

Ты так и не понял.

А правильный ответ в контексте твоей аналогии таков:

Вы когда заходите в телефонную будку и листаете справочник, сразу же тянетесь его «модифицировать»???

Нет, я открываю электронный справочник, ввожу имя и получаю телефон. Обоснуй, почему я должен тратить ресурсы (здесь: время) на то, чтобы листать справочник?

Нет, я открываю электронный справочник, ввожу имя и получаю телефон. Обоснуй, почему я должен тратить ресурсы (здесь: время) на то, чтобы листать справочник?

??? Я в полном ступоре, нельзя ли пояснее выражаться?

Как ты будешь апдейтить поле «число просмотров»?

Эээ, а оно зачем надо? Статистику собирать можно вообще незаметно для пользователя. Более того, пользователю нужны реальные данные, а не всякий «треш». Попробуй посмотреть на задачу иначе.

view'шки таки тоже ресурсы жрут, не?

Нет.

Лол.

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

Зачем, если мне нужен только телефон? Я хочу сделать так: getPhoneNumber(name). А ты предлагаешь делать так: SELECT phonenumber FROM phonebook WHERE name = :name, а потом ещё и прибиндить имя, а потом ещё выдёргивать из выборки это имя... Зачем, если меня эти все подробности не волнуют?

Это называется «инкапсуляция». Оставить только то, что нужно, остальное скрыть.

Открытые источники и нужны как раз тем разработчикам приложений, которые напишут хоть getPhoneNumber(name), хоть sendRocketToCallerID(phoneNumber). При этом общедоступные данные в первую очередь тем и хороши, что они не имеют никакого API кроме языка запросов. Это позволяет не принуждать анально к использованию всяких бл*дских языков типа Java, крайне неторопливо пережёвывающих XML-ки. Т.е. открытый источник данных позволяет следовать принципу бритвы Окама и не плодить новых сущностей без надобности. Особенно если эти сущности тебе навязываются и не соответствуют ни твоему мировоззрению, ни привычным методологиям программирования.

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

Эпично. Долго смеялся.

Почитал комментарии и сложилось впечатление, что ТСа почти никто не понял

++

Эпично. Долго смеялся.

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

Эээ, а оно зачем надо? Статистику собирать можно вообще незаметно для пользователя. Более того, пользователю нужны реальные данные, а не всякий «треш». Попробуй посмотреть на задачу иначе.

на самом деле, это не одна задача, а одна мечта + 100500 задач. Что-бы 100500 одминов озадачились открытием наружу 100500 СУБД.

Это позволяет не принуждать анально к использованию всяких бл*дских языков типа Java, крайне неторопливо пережёвывающих XML-ки. Т.е. открытый источник данных позволяет следовать принципу бритвы Окама и не плодить новых сущностей без надобности.

надобность тут есть. И даже две:

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

2. нужность прокладки также в том, что-бы лимитировать ресурсы, ибо самой СУБД это сделать тяжело.

Да и вообще, не забывай, что СУБД это прежде всего — работа. Если тебе нужен номер телефона в открытом тел. справочнике, то тебе его надо ещё там НАЙТИ. Девочки, которая будет его искать там нету. А ты — хочешь такую девочку. А кто ей будет платить? Сейчас эта девочка хоть рекламирует чего-то, а по твоему будет бесплатно работать?