https://wiki.python.org/moin/Templating

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

Mako забыли

f-строки наше все

Так, я понял

И что же тогда использовать?

Да что угодно, не важно какое качество ведь

Особенно, когда ничего подобного больше нет

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

вы мне про sql уже так же говорили

вы мне про sql уже так же говорили

чо

чо

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

sql - привет из 90

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

а зачем в боте голые sql запросы?

Экономия

В питоне*

sql - привет из 90

Альтернатива?

Ну вот так я пишу.

более того, зачем в боте sql?

Альтернатива?

key-value хранилища

А как ещё хранить записи пользователей?

А как ещё хранить записи пользователей?

см выше

в жсоне?

Ну такоооое

key-value хранилища

Браво (нет). В каком месте это альтернатива

в жсоне?

а в чем проблема?

Браво (нет). В каком месте это альтернатива

ээ, в любом вменяемом, где не нужны сложные реляции?

В том, что встроенный sqlite намного удобнее и проще в обращении.

В том, что встроенный sqlite намного удобнее и проще в обращении.

шта? с каких пор sql стал проще, чем .put()/.get()?

ээ, в любом вменяемом, где не нужны сложные реляции?

Какая не существенная оговорка про сложные реляции. Так вроде sql был именно придуман "для сложных реляций". Так, что попробуем еще раз. Альтернатива?

при всей моей любви к sql-базам, пихать их везде, включая телеграмных ботов с простой логикой - дикий оверхед

sql - привет из 90

серьезно ты это?

Какая не существенная оговорка про сложные реляции. Так вроде sql был именно придуман "для сложных реляций". Так, что попробуем еще раз. Альтернатива?

ты не просек фишку, в большинстве архитектур сложные реляции нафиг не нужны, а вот масштабирование - наоборот, нужно

Хз, меня не напрягает вручную писать sql запросы в коде и мне проще им дёргать информацию для разных пользователей по айдишникам.

в современном мире если тебе для телеграм-бота, который, скажем, устраивает викторины, нужен SQL - то ты что-то делаешь не так

в современном мире если тебе для телеграм-бота, который, скажем, устраивает викторины, нужен SQL - то ты что-то делаешь не так

а какие альтернативы?

Хз, меня не напрягает вручную писать sql запросы в коде и мне проще им дёргать информацию для разных пользователей по айдишникам.

ага, заодно появляются инъекции и баги в коде, плюс как-то с миграциями надо решать

а какие альтернативы?

зависит от задачи. Можно redis, можно tarantool, можно даже монгу изредка.

если текстов много - то elasticsearch

ты не просек фишку, в большинстве архитектур сложные реляции нафиг не нужны, а вот масштабирование - наоборот, нужно

Я то все просек. Ты просто видимо выпал из начала разговора. Первая фраза "sql - привет из 90", подразумевает, что это морально устаревшая технология. Морально устаревшей является такая, которой есть современная полноценная (подчеркну это) альтернатива. А такой нет. То, что sql не везде нужен, это другая тема.

сложно

> появляются инъекции и баги в коде чего нет - того нет. я предлагал людям уронить инъекцией - безрезультатно.

и что, скуль мешает масштабируемости?

в моем манямирке есть только скл

Я то все просек. Ты просто видимо выпал из начала разговора. Первая фраза "sql - привет из 90", подразумевает, что это морально устаревшая технология. Морально устаревшей является такая, которой есть современная полноценная (подчеркну это) альтернатива. А такой нет. То, что sql не везде нужен, это другая тема.

у него вышел новый стандарт с поддержкой JSON, если что

Я то все просек. Ты просто видимо выпал из начала разговора. Первая фраза "sql - привет из 90", подразумевает, что это морально устаревшая технология. Морально устаревшей является такая, которой есть современная полноценная (подчеркну это) альтернатива. А такой нет. То, что sql не везде нужен, это другая тема.

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

в моем манямирке есть только скл

ну так саморазвивайся, чо ты как этот

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

Супер) Согласен полностью

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

у него вышел новый стандарт с поддержкой JSON, если что

Так новый стандарт != новая технология. Не?

ну так саморазвивайся, чо ты как этот

ксти об этом. есть какой нибудь перечень фреймворков и библиотек?

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

поработай с postgresql, например

ксти об этом. есть какой нибудь перечень фреймворков и библиотек?

https://python3wos.appspot.com

поработай с postgresql, например

Оверкилл в данном проекте

Оверкилл в данном проекте

а что не оверкилл? sqlite?

https://python3wos.appspot.com

уууууу спасибо

а что не оверкилл? sqlite?

Хотя бы он, потому, что идёт в стандартной сборке.

Так новый стандарт != новая технология. Не?

SQL не такая уж и технология так-то, sql-подобный синтаксис поддерживают и no-SQL хранилища уже, так что от него никуда не деться в том или ином виде

Хотя бы он, потому, что идёт в стандартной сборке.

ну, идет или нет - это вообще неважно

как это неважно?

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

ты не просек фишку, в большинстве архитектур сложные реляции нафиг не нужны, а вот масштабирование - наоборот, нужно

так я не понял, можно ещё раз? скл мешает масштабируемости

так я не понял, можно ещё раз? скл мешает масштабируемости

в случае классических реляционных баз - да, мешает

точнее, мешает не sql, а архитектура этих самых баз

?

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

SQL не такая уж и технология так-то, sql-подобный синтаксис поддерживают и no-SQL хранилища уже, так что от него никуда не деться в том или ином виде

Ну я видимо немножко терминологию путаю возможно. Но суть вроде понятна - sql накладывает требования к структуре данных, и я к тому, что более эффективного пока нет. Видел я как sql в монге реализован в некторых тулзах. Блеванина, надо сказать, редкостная

ERROR: S client not available

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

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

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

Но пока как-то неубедительно.

точнее, мешает не sql, а архитектура этих самых баз

как?

как?

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

Про стандартную библиотеку аргумент можно распространить дальше, мол, зачем писать на питоне, если он требует дополнительно иметь интерпретатор питона, почему не на си

в случае современных kv-хранилищ ноды сами друг друга находят через мультикаст

там даже не надо ничего настраивать почти

Про стандартную библиотеку аргумент можно распространить дальше, мол, зачем писать на питоне, если он требует дополнительно иметь интерпретатор питона, почему не на си

Хорошая попытка, но в маразм лучше не ударяться.

Про стандартную библиотеку аргумент можно распространить дальше, мол, зачем писать на питоне, если он требует дополнительно иметь интерпретатор питона, почему не на си

А к си еще и компилятор нужен. Сразу машинные команды

Хорошая попытка, но в маразм лучше не ударяться.

ну вот "использую sqlite, потому что он в стандартной либе" - это примерно того же порядка маразм, а не аргумент

не надо гнаться за уменьшением количества зависимостей, надо задачи решать эффективно

а вот "использую sqlite, потому что это просто" - нормальный аргумент, на мой вкус

Как-то упустили изначальный аргумент, что "мне так удобно", но ладно.

Как-то упустили изначальный аргумент, что "мне так удобно", но ладно.

что на первом месте для тебя стоит в программировании - твое удобство или решение задачи?

скорость решения задачи, очевидно

Задача то решена.

она зависит от удобства

когда у тебя в руках молоток - все проблемы выглядят ,как гвозди

Но почему молоток здесь sql, а не json?

я тебе по секрету скажу то, на что выше намекал

ты можешь хранить json, например, в postgresql, и делать к нему запросы через sql

даже индексы строить по его полям

и это будет быстро и круто работать

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

зачастую это нетривиальная задача

но ты правильно сказал, что во многих случаях это оверкилл, так вот sql - это тоже оверкилл по сравнению с put/get в обычных хранилищах типа redis

но надо всегда исходить из задачи, а не из того, что у тебя есть или чего нет в стандартной либе

ребзи-ребзи, холивар

знакомый решил питонщина поискать, я говорю, что вилка у него говно )