DjangoBB LoFi version

Полная версия: В каком виде лучше хранить большие объемы данных для Python 3?

Начало » Базы данных » В каком виде лучше хранить большие объемы данных для Python 3?

1 2 3 4

JOHN_16

Ноя. 30, 2015 11:22:43

FanTech
sqlalchemy не имеет стабильной версии. Что реально напрягает.

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

Я надеюсь вы уже поняли что такое ORM, и почему ваше высказывание несостоятельное.

FanTech

Ноя. 30, 2015 12:48:42

4kpt_III
Посмеялся от души. Спасибо.

Не совсем понимаю, что вас так развеселило. Объясните, пожалуйста, почему я прогнал пургу?

JOHN_16
почему ваше высказывание несостоятельное.

А почему высказывание не состоятельно?

На официальном сайте самой SQLAlchemy это бета версия. Каждый раз выходят все новые и новые релизы в которых исправляют ошибки. Я хоть и не разбираюсь в реляционной теории, но насколько я понял SQLAlchemy это некий механизм взаимодействия между базой и Питоном. Следовательно он имеет синтаксис который как и любая другая логика может сбоить. Если я что-то не верно понимаю, пожалуйста, объясните по понятней.

JOHN_16

Ноя. 30, 2015 13:05:50

FanTech
по вашей логике версия 1.0 это стабильнейший релиз в котором нет ошибок. А 100% покрытие тестами говорит о 100% стабильности. Вот именно это и заблуждения.
Версификация в современном мире вообще перестала иметь однозначно важное значение. Чего стоит Хром и ФайрФОкс 40ых версий, а systemd 240 или сколько там, не помню. НУ а Линукс, который 2вой версией держался наверное с десяток лет,а за пару лет заимел версию 4. И т.п. историй много.
Каждый автор софта имеет свое видение и иерархию версионности того или иного проекта. И это не является показателем стабильности напрямую, а косвенно, да тоже нет - практика показывает.
100% покрытие тестами говорит лишь о том что для каждого куска кода проекта существует тестирующий код, при этом речь не идет о качестве самого теста т.о. существует вполне себе ситуация когда полностью покрытый тестами код даст ошибку, и это будешь лишь означать что для этого кода не написан тест который провоцирует полученную ошибку.
Это реальный мир и он сложнее и не однозначней, чем нам того хотелось бы.

FanTech

Ноя. 30, 2015 17:28:05

JOHN_16
Я вас понял.

Что касается базы. Я так понимаю, что SQlite в моем случае будет оптимальным выбором, так как большинство запросов к базе будет на чтение. Единственное чего я не понимаю, так это как взаимодействовать с ней в Питон 3? В PHP я использовал PDO при запросах к MySQL. В SQlite на Питоне я так понимаю эту роль выполняет SQLAlchemy? Или я заблуждаюсь?

И еще какими средствами можно представить SQlite в графическом виде (по типу PHPmyADMIN для MySQL, Access для mdb и т.д)? Кроме конечно блокнота. Я имею ввиду в табличном виде.

FishHook

Ноя. 30, 2015 17:34:10

FanTech
В питоне ты можешь обращаться к базе безо всяких ОРМов, если тебе так хочется. Создаешь соединение, курсор и вперед - посылай запросы. https://www.python.org/dev/peps/pep-0249/

FanTech

Ноя. 30, 2015 17:39:34

FishHook
В питоне ты можешь обращаться к базе безо всяких ОРМов, если тебе так хочется. Создаешь соединение, курсор и вперед - посылай запросы. https://www.python.org/dev/peps/pep-0249/

Спасибо, за ответ. Просто чем мне нравился PDO. При переходе на другую базу достаточно было изменить пару строк и все работает уже на другой базе. Да и безопасность контролировать было проще. А вот можете аналог PDO на питоне посоветовать? Это не SQLAlchemy?

4kpt_III

Ноя. 30, 2015 18:04:56

Откройте документацию или любую статью по sqlalchemy и все поймете…

P.S. Ну и не вспоминайте здесь PHP. Народ нервно реагировать может. Например, я

FishHook

Ноя. 30, 2015 18:05:46

FanTech
ОРМ создает те же самые запросы, тут нет никакой магии. Ты можешь написать как-то так

 query = Product.objects.all()

и получишь выборку из БД, серелализованную в набор питоньих объектов. ОРМ при этом сам создал запрос типа такого.

SELECT "ID", "NAME", "COST", "COUNT" FORM PRODUCT

, создал слединение, курсор, получил данные, и представил эти данные как список объектов.
Ты можешь все это делать сам. ОРМы написаны на питоне, значит тебе доступны все механизмы, которые они используют.

FanTech
При переходе на другую базу достаточно было изменить пару строк

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

#
# GET = {"name__icontains": "Шуба", "cost__range": [0, 100000]}
#
#
query = Product.objects.filter(**request.GET)

FishHook

Ноя. 30, 2015 18:07:33

FanTech
При переходе на другую базу достаточно было изменить пару строк

Ну и что? Посмотри сколько СУБД поддерживает алхимия, так для общего развития.

FanTech

Ноя. 30, 2015 19:34:01

4kpt_III
P.S. Ну и не вспоминайте здесь PHP. Народ нервно реагировать может. Например, я

Хорошо не буду. Сам пытаюсь с него перелезть на Питон, но пока еще не все понимаю. Многое не очень привычно. sqlalchemy ничего путного на русском найти не могу, что бы человечески разжевано было без этого академического сленга.

FishHook
Отлично разжевал. Вроде с ОРМ впитал что к чему. А вот такой еще вопрос. SQL в Питоне я же могу напрямую писать. Просто в Питоне немного иной диалект чем в PHP (ой, 4kpt_III, больше не буду) или все прямо так же?

И еще вопрос. По поводу SQlite:
1) И еще какими средствами можно представить SQlite в графическом виде (по типу PHPmyADMIN для MySQL, Access для mdb и т.д)? Кроме конечно блокнота. Я имею ввиду в табличном виде.
2) Как эту бумажку с данными запаролить? (может полную тупость спрашиваю, но реально не сталкивался с ней)