В этой главе наше внимание будет сосредоточено на по стоян но хра ня- щих ся данных, которые продолжают существовать после завершения создавшей их программы. По умолчанию это не так для объектов, создаваемых сценариями: такие объекты, как списки, словари и даже экземпляры классов, находятся в памяти компьютера и исчезают, как только сценарий завершает работу. Чтобы заставить данные жить дольше, требуется предпринять особые меры. В программировании на языке Python есть по крайней мере шесть традиционных способов сохранения информации между запусками программы:
Плоские файлы
Обеспечивают хранение текста и байтов непосредственно на компьютере
Файлы DBM
Обеспечивают доступ к строкам, хранящимся в файлах, напоминающих словари, по ключу
Сериализованные объекты
Сериализованные объекты могут сохраняться в файлах и потоках
Файлы хранилищ (shelve)
Обеспечивают хранение сериализованных объектов в файлах DBM
Объектно-ориентированные базы данных (OODB)
Обеспечивают сохранение объектов в хранилищах, имеющих структуру словарей (ZODB, Durus)
Реляционные базы данных SQL (RDBMS)
Хранилища в виде таблиц, поддерживающие запросы SQL (SQLite, MySQL, PostgreSQL и другие)
Объектно-реляционные отображения (ORM)
Промежуточные механизмы, обеспечивающие отображение классов Python в реляционные таблицы (SQLObject, SQLAlchemy)
В некотором смысле интерфейсы Python к сетевым протоколам передачи объектов, таким как SOAP, XML-RPC и CORBA, также предоставляют возможность сохранения данных, но их описание выходит далеко за рамки этой главы. Интерес для нас здесь представляют приемы, позволяющие программам сохранять данные непосредственно и, обычно, на локальном компьютере. Некоторые серверы баз данных могут действовать на удаленном компьютере в сети, однако в целом это не имеет значения для большинства приемов, которые мы будем изучать здесь.
Мы изучали интерфейсы Python простых (или «плоских») файлов в главе 4 и с того момента пользуемся ими. Python предоставляет стандарт
ный доступ к файловой системе stdio (через встроенную функцию open), а также на низком уровне — через дескрипторы файлов (с помощью встроенного модуля os). Для простых задач хранения данных многим сценариям ничего другого не требуется. Чтобы сохранить данные для использования при следующих запусках программы, нужно записать их в открытый файл на компьютере, а потом прочитать их обратно из этого файла. Как мы видели, в более сложных задачах Python поддерживает также другие интерфейсы, сходные с файлами, такие как каналы, очереди и сокеты.
Так как мы уже знакомы с плоскими файлами, я не буду больше рассказывать здесь о них. Оставшаяся часть главы знакомит с другими темами из списка, приведенного в начале раздела. В конце мы также познакомимся с программой с графическим интерфейсом для просмотра содержимого файлов хранилищ и файлов DBM. Но прежде нам нужно разобраться, что это за звери.
Примечание к четвертому изданию: В предыдущем издании этой книги использовался интерфейс mysql-python к системе управления реляционными базами данных MySQL, а также система управления объектно-ориентированными базами данных ZODB. Когда я занимался обновлением этой главы в июне 2010 года, ни один из них еще не был доступен в Python 3.X — версии Python, используемой в этом издании. По этой причине большая часть информации о ZODB была убрана из главы, а примеры работы с базами данных SQL были переориентированы на использование интерфейса SQLite к базе данных внутри процесса, который входит в состав стандартной библиотеки Python 3.X. Примеры использования ZODB и MySQL и обзоры из предыдущего издания по-прежнему доступны в пакете примеров к книге, как будет описано ниже. Однако благодаря переносимости интерфейса к базам данных SQL в языке Python, программный код, использующий SQLite, практически без изменений сможет работать с большинством других баз данных.
Использованная литература:
Марк Лутц — Программирование на Python, 4-е издание, II том, 2011
