Как построчно вывести названия столбцов по значению?

Timebird, Ах, да. Нельзя просто так взять и сравнить два float. Нужно либо приывести к int, либо вот так - https://docs.python.org/3/whatsnew/3.5.html#pep-48...

Как поднять сервер на Linux и задеплоить приложение?

Viktoria Smirnova, ждем адрес сайта ;-)

Как сделать smtp сервер?

Борис Сёмов, но уж точно не sendmail :-)
Не прост, конечно, но достаточно прост в обращении, в отличии от того же exim, и достаточно просто в поднятии. в отличии от postfix с его паранойей по безопасности. Да я и не настаиваю, нравится постфикс или экзим - пожалуйста. Я вот от них сбежал, че5му рад и делюсь с окружающими.

Как поднять сервер на Linux и задеплоить приложение?

Поддержу предыдущего оратора. И задам наводящий вопрос. На чем писали (какое IDE использовали) и проект какого типа делали? J2ee проект, web-проект?
Есть ли ear.xml или web.xml?

Как лучше (дешевле) хранить справочники?

d-stream, с тегими все хорошо, постгрес есть, php тоже. Все реализуется на раз и на том и на другом.

Как лучше (дешевле) хранить справочники?

d-stream, Утрированный пример... Да уж... Я немного, как понимаете, из другого мира... Большие дяди уже давно и такое придумали, лет эдак 20 назад. Называется - распределенная транзакция, в частности реализована и не первой, например в JEB. Это когда данные за Уралом, а заказчики в Австралии, смежники в штатах, и все в одной "распределенной" транзакции. А одна из первых реализаций - стандарт CORBA на основе RPC.
Нравится вам SQL, он мне тоже нравится, и распределенные транзакции нравятся, и noSQL нравится. И я не боюсь ни того, ни другого, ни третьего, но всему свое место, и зачастую не нужно ездить не танке и вспахивать поле.

Еще раз - SQL совсем не про атомарность! Вообще! Иначе зачем оно нужно придумывать какие-то к хрену уровни изоляции. Ставим seriazable и, типа жывем, как-то.

Подробный хелп в консоли - это возможно?

Ну... встроенный хелпер достает только ту информацию, что описана в самом коде мадуля/функции, не более... обычно этого хватает, но не всегда
Вам здесь почитать - https://docs.python.org/3.4/library/string.html#st...

Как лучше (дешевле) хранить справочники?

d-stream, поясните, что имеете ввиду под "уровнями" высокими и низкими, и что не хотите использовать? атомарность?
Ну, давайте я все записи буду поменять каким-то уникальным ID, и буду вести журнал этих ID и самих записей? это будет похоже на внутренности постгрес или оракл? Вопрос на засыпку...

Как вывести цветной текст на Python?

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

Как лучше (дешевле) хранить справочники?

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

Как лучше (дешевле) хранить справочники?

d-stream, sql (точнее - базам данных) не нужно быть атомарным, у них совсем другая задача, обеспечить целостность (консистентность) данных, и только! Про атомарность - это совсем из другой оперы.
И вот если всерьез поразмыслить над консистентностью (атомарность как совсем частный случай), то мы придем к совершенно разным ее реализациям. Версионностью, как в оракл или постгрес; блокировками и журналами, как в сайбейс, эмэссиквел; журналированием, как в дб2. Что же касается транзакций, то это тоже, всего лишь одно из решений обеспечения целостности.
Так что, боюсь, вам следует отбросить ваши учебники по sql, и прочитать таки введение в теорию баз данных.

ЛУчше цитатами из учебников

Набор принципов, определяющих организацию логической структуры хранения данных в базе, получил название модели данных. Модели баз данных определяются тремя компонентами:
- допустимой организацией данных;
- ограничениями целостности;
- множеством допустимых операций.

И да, если интересно, могу и развернуто, часами и курсами.

Как обработать внешний API используя Flask?

Jekson, Аккуратнее, там есть ограничения на трафик :-)

Как обработать внешний API используя Flask?

Если у вас json, для чего все усложнять?
Вот пример, на коленке :-) (и да, я люблю этот сайт https://swapi.co и фильм )

>>> import  requests
>>> res = requests.get("https://swapi.co/api/people/")
>>> for actor in res.json()["results"]:
...   print actor["name"]
...
Luke Skywalker
C-3PO
R2-D2
Darth Vader
Leia Organa
Owen Lars
Beru Whitesun lars
R5-D4
Biggs Darklighter
Obi-Wan Kenobi
>>>

Подробный хелп в консоли - это возможно?

Так пробовали?
>>> help(str)

Как обработать внешний API используя Flask?

Jekson, А, ну тогда понятно, да, flask тогда пойдет.

Не забудьте - фласк однопоточный, и если вам нужно забирать данные с внешнего API, то лучше использовать для этого очереди задач типа python-rq или celery. Другими словами, не запускайте внутри фласка долгоиграющих задач, а просто публикуйте задание в очередь.
Отдельный воркер (или несколько воркеров), который слушает очередь, будет забирать данные (requests, о нем я уже писал), фильтровать, и сохранять в собственную базу.

Что касается flask. Фласк будет показывать обработанные данные из вашей базы. Определитесь, где будуте хранить данные для обработки - SQL, noSQL, или что-то еще. В принципе, после того, как определились, задавайте вопросы по конкретной технологии.

В общем.
1) определиться с очередью - рекомендую начать с python-rq, как простой и достаточно надежной.
2) определиться с хранилищем (база данных) и
3) написать воркеров (к фласку это пока никак не относится)
4) написать api на flask под готовые данные и базу

Как лучше (дешевле) хранить справочники?

Спасибо :-)

Как лучше (дешевле) хранить справочники?

vyachin, Вы меня не полностью читали, я уже писал, что

Конвертировать строку в любой тип на программном уровне вообще без проблем!

и

Какие запросы мы делаем к справочнику? Получить значение по ключу и/или по ИД, обратных запросов вообще практически нет.

И да, отступаем от первой нормали, что в этом плохого?

PS. Реляционные базы отложил, лет эдак 10 назад после лет эдак 10 непрерывного использования. И последние лет эдак 10 занимаюсь noSQL и не только, а учебников тогда еще не было. И да, я старый хрен, для кого-то почти старик, но девочки западают, челюсть не висит!

Как лучше (дешевле) хранить справочники?

vyachin, давайте немного остановимся
1) я говорил совсем не о конкретной реализации, а о принципе хранения, что и вопрошал автор вопроса!
2) как приблизительный пример привел на скорую руку (!!!) первое, что пришло в голову и соответствует моей идее.
3) автор вопроса вообще не дал никаких данных по полям/объектам и прочей фигни, так что разбирать досконально, какие поля должны быть в какой таблице, смысла не вижу.
4) Вы мне ставите в укор не принцип хранения (смотрим суть вопроса(!)) а пример, к делу совсем не относящийся, приведенный для полноты картины. Не находите странным?

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

Таблица характеристик (можно сделать отдельно группировку по группам, добавить доступы, множественные значения и т.д., но здесь это рассматривать совсем не собираюсь)
PropNames
prop_id (number) | name (char) | type (char)
1 | color | string
2 | weigth | long

Таблица значений характеристик, связанная с товаром
PropValues
product_id (number) | prop_id (number) | value (char)
1000 | 1 | red
1000 | 2 | 10.0

И да, на этом дискуссию завершаю.

Как лучше (дешевле) хранить справочники?

Отвечу просто, я не сторонник городить трехэтажные джоины, я сторонник переносить всю возможную логику на программную сторону. Поэтому всем рекомендую сделать пару (а может и десятка два) лишних запроса, вместо попытки получить все в одном. На то есть ряд проверенных временем и производительностью оснований.
1) простые запросы легче прожевываются оптимизатором и самой базы, и легче кешируются на стороне базы.
2) простые запросы легче кешируются на стороне приложения.
3) любая база данных, если мы говорим про sql, ресурс сильно ограниченный лицензиями, потоками, производительностью сервера, возможностью расширения (и тд), поэтому его крайне нежелательно нагружать триггерами, хранимками, сложными запросами в стиле olap, и прочей чушью. Главная задача базы -обеспечивать консистентность хранимой информации. Дя, я понимаю, что планировщики могут прожевать запрос на 200 таблиц и тыщщу полей с джоинами сабселектами, хранимками по триггерам (а еще это просто красиво), но кому оно нужно, когда пара таких запросов выбивает полностью кеш базы, превращая всю производительность сотен тысяч долларов в тормозного червя.
4) вычислительную мощность программной части гораздо легче нарастить, как по горизонтали, так и по вертикали. На текущий момент купить еще один сервер/инстанс для бекенда проще на порядок, чем сделать мастер-слев реплику любой базы. В программной части мы практически не ограничены в ресурсах (при хоть немного правильной архитектуре), а вот с базами данных такой фокус желательно закладывать на этапе проектирования! Имея один-два сервера бд, пару кеширующих серверов и с десяток бекендов нам проще выполнить с десяток запросов, четко попадающих в кеши к десятку таблиц, чем городить джоины на сотню.
5) программный код легче поддерживать, отлаживать и модифицировать, чем бороться с эксплейнами, сбросами кешей базы и отладкой sql,причем мапинг домен-данных будет на порядок проще, как и отладка бизнес-логики на их основе.
6) нужно генерировать отчеты, берите olap или nosql, и не терзайте то, для чего оно не предназначено.

Как лучше (дешевле) хранить справочники?

d-stream, что такое справочник? Обычно это ключ-значение-тип-ид. Какие запросы мы делаем к справочнику? Получить значение по ключу и/или по ИД, обратных запросов вообще практически нет. Конвертировать строку в любой тип на программном уровне вообще без проблем! Это конечно не касается случаев, когда у нас например счетчики, но тогда это и не справочник.можно конечно сказать, что строка и число занимают совсем разное место. Да можно, но во первых - это таки справочник, во вторых никто нам не запрещает иметь и числовые справочники отдельными таблицами... Но вот отдельная таблица на каждый справочник - я такое у себя не позволю, уж очень серьезные аргументы мне нужно привести, почему нужно на 10-20 значений заводить таблицу! Да, может быть мускул к этому и подталкивает, но вот в сайбейс или какой другой энтерпрай-базе, таблица, не хрен собачий, и иногда на десяток записей жрет места больше них самих.