база данных Python / sql программирующий - где запустить

I highly recommend the use of a good ORM. When you can work with Python objects to manage your database rows, life is so much easier.

I am a fan of the ORM in Django. But that was already recommended and you said that is too heavyweight.

This leaves me with exactly one ORM to recommend: Autumn. Very lightweight, works great with SQLite. If your embedded application will be multithreaded, then you absolutely want Autumn; it has extensions to support multithreaded SQLite. (Full disclosure: I wrote those extensions and contributed them. I wrote them while working for RealNetworks, and my bosses permitted me to donate them, so a public thank-you to RealNetworks.)

Autumn is written in pure Python. For SQLite, it uses the Python official SQLite module to do the actual SQL stuff. The memory footprint of Autumn itself is tiny.

I do not recommend APSW. In my humble opinion, it doesn't really do very much to help you; it just provides a way to execute SQL statements, and leaves you to master the SQL way of doing things. Also, it supports every single feature of SQLite, even the ones you rarely use, and as a result it actually has a larger memory footprint than Autumn, while not being as easy to use.

Я начал здесь:

http://www.devshed.com/c/a/Python/Using-SQLite-in-Python

Это 5 (короткие) страницы с мне сразу же помогло только самое необходимое.

What you're looking for is SQLAlchemy, which is fast becoming the de facto standard Python data access layer. To make your first experiences with SQLAlchemy even easier, check out Elixir, which is a thin ActiveRecord-style wrapper around SQLAlchemy.

Update: Reread the question and saw the bit about not needing a full ORM. I'd still suggest going the SQLAlchemy route, just because it gives you a ridiculously easy way to work with databases in Python that you can reuse for any kind of database. Time spent working directly with SQLite is wasted once you need to connect to Oracle or something.

начните с Django

http://www.djangoproject.com/

ORM - это то, что вам нужно. Вы не пожалеете. Учебник здесь http://docs.djangoproject.com/en/dev/intro/tutorial01/ довольно мягкий.

Почему Django / ORM? Django запустит вас примерно через полчаса, будет управлять соединениями с базой данных, интерфейсами управления данными и т. Д. Django работает с SQLLite: вам не нужно управлять экземпляром MySQL / PostGre.

EDIT1: вы не делаете ' Для этого не нужно использовать часть Django для веб-приложений. Вы можете использовать классы db.Model для непосредственного управления вашими данными. Какое бы автономное приложение / скрипт вы ни придумали, вы можете просто использовать уровень модели данных Django. И когда вы решите, что вам нужен веб-интерфейс,

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

Я не уверен, откуда у вас действительно «тяжелая работа». Django значительно меньше по объему строк кода, чем любой другой крупный фреймворк для веб-приложений.

Еще один вариант, который можно добавить к другим хорошим предложениям: Эликсир . Он обеспечивает упрощенный декларативный уровень поверх SQLAlchemy , поэтому в него должно быть легче погрузиться, но он также позволяет использовать всю мощь SQLAlchemy , если и когда вам нужно это.

Существует простой в использовании модуль Python, который отвечает всем заявленным целям:

http://yserial.sourceforge.net/

Сериализация + постоянство: сжатие и аннотирование Python в несколько строк кода объекты в SQLite; а затем извлекать их в хронологическом порядке по ключевым словам без SQL. Самый полезный «стандартный» модуль для базы данных для хранения данных без схемы.

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

Что касается «защиты меня от реальной базы данных». "с y_serial даже нельзя сказать, что за всем этим стоит SQLite. Если вы строите свои записи как словари Python, вы можете сосредоточиться только на написании кода (а не хранимых процедур).