On 23 October 2017 at 21:37, John Black <jbl...@nopam.com> wrote: > Chris, thanks for all this detailed information. I am confused though > with your database recommendation. You say you teach SQLAlchemy but > generally use PostgreSQL yourself. I can maybe guess why there seems to > be this contradiction. Perhaps PostgreSQL is better but too advanced for > the class you are teaching? Can you clarify on which you think is the > better choice? Thanks.
Different Chris, but I’ll answer. Those are two very different things. PostgreSQL is a database server. It talks SQL to clients, stores data, retrieves it when asked. The usual stuff a database server does. Alternatives: SQLite, MySQL, MS SQL, Oracle DB, … SQLAlchemy is an ORM: an object-relational mapper, and also a database toolkit. SQLAlchemy can abstract multiple database servers/engines (PostgreSQL, SQLite, MySQL, etc.) and work with them from the same codebase. It can also hide SQL from you and instead give you Python classes. If you use an ORM like SQLAlchemy, you get database support without writing a single line of SQL on your own. But you still need a database engine — PostgreSQL can be one of them. But you can deploy the same code to different DB engines, and it will just work™ (assuming you didn’t use any DB-specific features). Alternatives: Django ORM. psycopg2 is an example of a PostgreSQL client library for Python. It implements the Python DB-API and lets you use it to talk to a PostgreSQL server. When using psycopg2, you’re responsible for writing your own SQL statements for the server to execute. In that approach, you’re stuck with PostgreSQL and psycopg2 unless you rewrite your code to be compatible with the other database/library. Alternatives (other DBs): sqlite3, mysqlclient. There are also other PostgreSQL libraries available. -- Chris Warrick <https://chriswarrick.com/> PGP: 5EAAEA16 -- https://mail.python.org/mailman/listinfo/python-list