Запросы к Twitter API на синтаксисе SQL

[deniskin]

Родители Анатолия — программисты. Отец и мать. Нет ничего удивительного в том, что сын разбирается в программировании.

[nekritik]

Неужели, администрация хабра начала заказывать своим журналистам не только новостные, но и технические статьи…

[drunken]

пропиарили бобука, будет теперь хвастаться SQL-запросом :)

[Sannis]

> TweeQL закодирован на Python.
OMG! Он закодирован!

[Ctacok]

А мы кашку ели, а мы гуляли, но мы не знали что такое обфусификация))

[mezastel]

Не хочу никого обижать, но SQL must die!

[widowmaker]

Покормить вас что-ли, уж сильно проголодались, ну очень толсто.
Где факты, сравнение, интриги, расследования?

[AusTiN]

Вконтакте, Фейсбук и куча других крупных проектов работающих на *SQL не одобряют этот комментарий.

[b0n3Z]

Вконтакте, Фейсбук и другие крупные проекты не используют фичи SQL типа join, group by и тяжелые запросы тоже.
Более того, во Вконтакте sql только как legacy штука стоит. У них собственная БД.
В фейсбуке все базы в формате key-value. Это sql назвать нельзя, я считаю.

[centur]

Дмитрий, мне кажется вы слишком увлекаетесь альтернативными взглядами. SQL это язык запросов. Он может являться надстройкой не только над реляционными БД. Например Azure SQL =) такая мертвая тенденция, что прямо удивительно, что MS уделили ей место в keynote.
ИМХО сложно представить что-то более удобное и понятное для создания разноплановых запросов чем SQL.

[mezastel]

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

[centur]

ага, по вам лучше все дергать по индексам из массивов, зато быстро…

[GetWindowsDirectory]

Обидели

[Zubchick]

Здорово, а в программы на питоне встроить можно?

[Zubchick]

хотя, учитывая кто автор, наверно будет проще самому разобраться)

[alprk]

from tweeql.exceptions import TweeQLException
from tweeql.query_runner import QueryRunner

runner = QueryRunner()
runner.run_query("SELECT text FROM twitter_sample;", False)


[AgentSmith]

Facebook это первым сделал, разработав FQL

[AgentSmith]

Пёрнуть ещё надо, и будет настоящий американский юмор.
Тогда можно будет смеяться.

[Mezomish]

Более того: FQL допускает множественные и вложенные запросы. Например,

"query1":"SELECT uid, rsvp_status FROM event_member WHERE eid=12345678"
"query2":"SELECT name, url, pic FROM profile WHERE id IN (SELECT uid FROM #query1)"

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

Интересно, как с этим у сабжа?

[soldovskii]

а у .NET'чиков уже давно был LINQ to Twitter ^_^

[soldovskii]

Видимо писать начали одновременно =)

[Setti]

Всё это без необходимости думать о всех деталях для правильного API-запроса.

Ирония в том, что даже посредством родных запросов через API, сложные конструкции блокируются твиттером из-за их ресурсоёмкости. Чего уж там про SQL-подобные выборки говорить.

[VasilioRuzanni]

Ну сделали — молодцы, что тут скажешь. Единственное, что интересно — зачем?

Тут, значит, наоборот пытаемся абстрагироваться от источников данных, используя REST, Data-сервисы, ORM, создаем LINQ-провайдеры ко всему и вся, пытаемся избавиться от magic-strings, используем NoSQL-хранилища там, где реляционные связи не дают должного профита, а тут внезапно появилась возможность использовать SQL там, где его изначально можно не использовать, да и быть не должно. Как по мне, это примерно как использовать SQL для доступа к свойствам объектов внутри ООП-языка.

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

[b0n3Z]

Лично мне SQL хорошо понятен.
В данном случае не нужно тратить время на изучение api твиттера, достаточно просто просмотреть названия баз\полей и сделать нужную выборку. Очень удобно.
Я сам писал такую штуку для вконтактика, проект забросил, к сожалению.

[VasilioRuzanni]

«достаточно просто просмотреть названия баз\полей и сделать нужную выборку»
Так вот вам и изучение API.

Но «просмотрев поля» — так и придется сформировать API самому, для своего проекта.

SQL — понятен, потому что стандартизирован. Но я придерживаюсь точки зрения, что SQL — не самая понятная вещь.

[b0n3Z]

Да, к сожалению, не самая.
Кстати, если каждый сайт будет использовать sql-like api на сайтах, то получим еще один хороший стандарт. Сейчас, вроде, каждый сайт городит что-то свое.

[VasilioRuzanni]

Стандарт есть — и это SOAP, и REST, не совсем стандарт, но на нем можно основать множество хороших соглашений. SOAP не сказать, что хорош, но SQL в любом случае не лучше. Но это, конечно, imho.

[iStyx]

Как по мне, это примерно как использовать SQL для доступа к свойствам объектов внутри ООП-языка

Судя по всему, вы не сталкивались с NSPredicate

[VasilioRuzanni]

Нет, не сталкивался, но сейчас посмотрел. К чему вы его отметили?