Does Python have its own libraries for working with DBMS (like PHP)?

  • one
    For most DBMS / operating systems - yes. If not, then there are means of calling functions on C and there you can use the API proposed by the developers of the DBMS. - alexlz

5 answers 5

Yes, of course, and for very many DBMS. However, working directly with the DBMS is sad and (ideologically) wrong. It is much more convenient to use ORM (object-relation mapping); in Python, SQLAlchemy is the most common and the add-on is Elixir

  • one
    > (ideologically) wrong What is your ideology? - rnd_d
  • Ideology - the creation of portable, supported code. - SAABeilin 1:09 pm
  • one
    Is portable portable or tolerable? - alexlz
  • :-))) Well, in a sense, both :-) - SAABeilin
  • 2
    You forget that ORM is only suitable in simple cases. For complex applications, they are unsuitable because it is difficult or even impossible to express a complex query in terms and means of ORM. - cy6erGn0m

To the main database, Python has any and not one at a time.

In my work I use sqlite, Firebird and Postgresql.
For example, a piece of code for Postgresql:

#-*- coding: UTF-8 -*- import pg pgcon=None def opendb(host,base,user,password): global pgcon pgcon=pg.connect(dbname=base,host=host,user=user,passwd=password) def closedb(): global pgcon pgcon.close() def querysql(val): global pgcon pgcon.query(val) pass def queryparam(sql_val,param): global pgcon pgcon.query(sql_val % pg.escape_bytea(param)) def queryresparam(val): global pgcon f=pg.unescape_bytea(pgcon.query(val).getresult()[0][0]) return f def querysqlres(val): global pgcon data=pgcon.query(val).getresult() return data
  • As is the case with MySQL, this is a highly platform dependent code. Once again, I would recommend to look in the direction of ORM, which, firstly, make the code maximally portable between different DBMSs, and secondly, they simplify work with the database, making it particularly object-oriented. - SAABeilin pm
  • the funny thing is not much. because working with databases in python is done in the same way. Using ORM in most cases is not justified. Because you can not use the "goodies" of the database, and use for example the same Oracle as just a data storage, it is somewhat wasteful. - cavinc
  • @cavinc, do not forget about screening and other nuances of making requests. SQL injections are still relevant, and how many bugs come out! And I emphasize once again that through ORM you can perfectly use the specifics of the underlying DBMS. I note that we personally (our company) uses ORM, and the specifics of the DBMS. - SAABeilin

You need to deliver mysql-python (it seems so called), but in general a search in Google gives a good result)

    Here is a simple example, I think you will understand

     import _mysql db=_mysql.connect("localhost","user", "pass", "base") db.query(r"SELECT field1, field2 FROM table1 WHERE field1 < 5") r=db.store_result() print(r.fetch_row())

      All popular databases in the python community have their own packages.

      MySql-Python for Mysql
      psycopg2 for postgresql
      sqlite3 for Sqlite3
      etc. These are essentially packages with low-level C extensions for interacting with the database.

      Any ORM is usually an add-on over low-level C extensions (as in Sqlalchemy) or over low-level C extensions (as in the orm in the django framework).

      And to use always and everywhere ORM is EVIL . Using ORM should be dictated by the task, and not vice versa.

      • one
        Suspecting that the Author of the question wants to work with a DBMS for storing data there, I recommend using ORM there. Moreover, usually ORM allows you to perform arbitrary (read, platform-dependent, and in particular maintanance) SQL queries (for example, I sometimes use this opportunity in SQLAlchemy) I will add 99% of database tasks associated with storing data there that is not DBMS perfectly fit on some object model. Therefore, ORM should be used in 99% of cases. And that same 1% only confirms this rule :-) - SAABeilin
      • ORM imposes a number of restrictions. This use of triggers, complex cascade queries, temporary tables, procedures, mountains. and vert. sharding and other necessary subtleties that are only in one of the bases and ORM limits their use. In addition, ORM eats CPU time on its code. That is why the use of ORM is abandoned in simple programs and high-load systems. I am not an opponent of ORM, but rather a supporter, but I still think that 99% is a very large percentage. IMHO, for 60% -70% of cases, ORM will be suitable and 30-40% of cases of using ORM will be superfluous. - Antik
      • But ORM does not prohibit their use! On the contrary, by making platfrom-specific requests via ORM, you can get at the output not a raw rowset, but quite an object list itself. PS By the way - somehow I looked with different means at loading one real server. And so ORM there generally less than 1% gave. I ate a lot of the template engine, but most actively, the most seemingly normal queries to the database. The scheme was made according to all canons, there was practically no place to improve. - SAABeilin 2:51 pm