Python Anfängerfragen
Ich möchte mit der ersten Anwendung verschiedene Informationen über Kunden und deren Server aus einer Datenbank auslesen und speichern können. Das ich zum Beispiel die IP Adressen von einem SErver eingeben kann und dann Information über den Kunden und die vorhandenen Zugriffe und Passwörter und so erhalte.
- Hyperion
- Moderator
- Beiträge: 7478
- Registriert: Freitag 4. August 2006, 14:56
- Wohnort: Hamburg
- Kontaktdaten:
Das kann man doch auch ohne GUI! Die benötigten Parameter kann man leicht an ein CLI übergeben. Wobei das alles im Moment eher nach Dumpen von Daten klingt... da sehe ich nocht nicht den Nutzen von Python.pole23 hat geschrieben:Ich möchte mit der ersten Anwendung verschiedene Informationen über Kunden und deren Server aus einer Datenbank auslesen und speichern können. Das ich zum Beispiel die IP Adressen von einem SErver eingeben kann und dann Information über den Kunden und die vorhandenen Zugriffe und Passwörter und so erhalte.
Auf jeden Fall hast Du mit dem DB-Modul oder ggf. einem ORM genug am Hacken für den Anfang. Da würde ich mir nicht noch ne GUI aufhalsen.
encoding_kapiert = all(verstehen(lesen(info)) for info in (Leonidas Folien, Blog, Folien & Text inkl. Python3, utf-8 everywhere))
assert encoding_kapiert
assert encoding_kapiert
Ich wollte mit Python generell mal anfangen und da fiel mir das Projekt halt als erstes ein. Aber du hast recht, ich werde erstmal versuchen, ein alles Konsolenbasierend zum laufen zu bekommen, was mit Sicherheit schwer genug seien wird:-)
- noisefloor
- User
- Beiträge: 3856
- Registriert: Mittwoch 17. Oktober 2007, 21:40
- Wohnort: WW
- Kontaktdaten:
Hallo,
wenn es um die reine Abfrage gem. deinem Beispiel geht, dann sollten das in Python ~10 Zeilen Code sein. Wenn man "schön" formatieren will vielleicht auch ein paar mehr.
Gruß, noisefloor
wenn es um die reine Abfrage gem. deinem Beispiel geht, dann sollten das in Python ~10 Zeilen Code sein. Wenn man "schön" formatieren will vielleicht auch ein paar mehr.
Gruß, noisefloor
- noisefloor
- User
- Beiträge: 3856
- Registriert: Mittwoch 17. Oktober 2007, 21:40
- Wohnort: WW
- Kontaktdaten:
Hallo,
egal - für jeden Query werden es 2 Zeilen mehr für die Abfrage und mindestens 2 für die Ausgabe.
Gruß, noisefloor
egal - für jeden Query werden es 2 Zeilen mehr für die Abfrage und mindestens 2 für die Ausgabe.
Gruß, noisefloor
- Hyperion
- Moderator
- Beiträge: 7478
- Registriert: Freitag 4. August 2006, 14:56
- Wohnort: Hamburg
- Kontaktdaten:
Oder einem ORM wie SQLALchemy oder Elixir. Ansonsten: Ja.
Ist MySQL vorgegeben?
Ist MySQL vorgegeben?
encoding_kapiert = all(verstehen(lesen(info)) for info in (Leonidas Folien, Blog, Folien & Text inkl. Python3, utf-8 everywhere))
assert encoding_kapiert
assert encoding_kapiert
- noisefloor
- User
- Beiträge: 3856
- Registriert: Mittwoch 17. Oktober 2007, 21:40
- Wohnort: WW
- Kontaktdaten:
Hallo,
@pole23: Zum Zugriff auf eine DB brauchst du immer ein passendes Modul. das für SQLite3 ist bei Python seit Version 2.5 (?) an Bord, für MySQl oder PostgreSQL oder oder oder musst du das nachinstallieren. Was aber sehr einfach ist.
Python besitzt zumindest für relationale Datenbanken eine einheitliche API - d.h. der Wechsel von z.B. SQLite auf MySQL ist in der Regel mit der Änderung einer Code-Zeile möglich (vorausgesetzt, dass im sonst im Prog keine für eine DB-spezifischen Befehle hast).
Ob du ein ORM benutzt, wie man Hyperion angedeutet, hängt davon ab, was du später vor hast. Das Einarbeiten in ein ORM ist halt zusätzlicher Aufwand, der aber (am Anfang) lange nicht so hoch ist wie PyGTK oder PyQt lernen.
Gruß, noisefloor
Oder Storm.Oder einem ORM wie SQLALchemy oder Elixir
@pole23: Zum Zugriff auf eine DB brauchst du immer ein passendes Modul. das für SQLite3 ist bei Python seit Version 2.5 (?) an Bord, für MySQl oder PostgreSQL oder oder oder musst du das nachinstallieren. Was aber sehr einfach ist.
Python besitzt zumindest für relationale Datenbanken eine einheitliche API - d.h. der Wechsel von z.B. SQLite auf MySQL ist in der Regel mit der Änderung einer Code-Zeile möglich (vorausgesetzt, dass im sonst im Prog keine für eine DB-spezifischen Befehle hast).
Ob du ein ORM benutzt, wie man Hyperion angedeutet, hängt davon ab, was du später vor hast. Das Einarbeiten in ein ORM ist halt zusätzlicher Aufwand, der aber (am Anfang) lange nicht so hoch ist wie PyGTK oder PyQt lernen.
Gruß, noisefloor
- Hyperion
- Moderator
- Beiträge: 7478
- Registriert: Freitag 4. August 2006, 14:56
- Wohnort: Hamburg
- Kontaktdaten:
Wenn Du dann Features wie Netzwerkzugriff, Userverwaltung usw. nicht benötigst, würde ich auf SQLite setzen.
Je nach dem, was für Daten Du ablegen musst und wie diese strukturiert sind, kommen dann aber auch noch Key-Value-Stores oder Dokumenten-zentrierte Datenbanken in Frage (Stichwort NoSQL). Bekannte Vertreter sind da MongoDB, CouchDB, Tokyo-Cabinett, uvm.
Wenn Du uns da mehr Auskunft geben könntest, wäre da eine Empfehlung für Dich denkbar.
Je nach dem, was für Daten Du ablegen musst und wie diese strukturiert sind, kommen dann aber auch noch Key-Value-Stores oder Dokumenten-zentrierte Datenbanken in Frage (Stichwort NoSQL). Bekannte Vertreter sind da MongoDB, CouchDB, Tokyo-Cabinett, uvm.
Wenn Du uns da mehr Auskunft geben könntest, wäre da eine Empfehlung für Dich denkbar.
encoding_kapiert = all(verstehen(lesen(info)) for info in (Leonidas Folien, Blog, Folien & Text inkl. Python3, utf-8 everywhere))
assert encoding_kapiert
assert encoding_kapiert
Also vom Prinzip her hatte ich folgendes vor. Wir haben mehrere Kunden mit mehreren Servern. Und es kommt schon mal vor, dass man zum Beispiel eine IP Adresse hat, aber nicht genau weis, was für Dienste, Benutzer auf dem Server eingerichtet sind oder wo die Maschine ist. Daher hatte ich an ein Tool gedacht, wo man die IP oder den Namen vom Server eingibt und dann die nötigen Informationen erhält. Es soll natürlich auch möglich sein, neue Daten(Server) eingeben zu können. Eine Benutzerverwaltung wäre hatte ich vor, da nicht jeder diese Daten sehen soll.
Ich hoffe das hat etwas geholfen.
Ich hoffe das hat etwas geholfen.
- Hyperion
- Moderator
- Beiträge: 7478
- Registriert: Freitag 4. August 2006, 14:56
- Wohnort: Hamburg
- Kontaktdaten:
Das könnte man durchaus mit einem NoSQL-Ansatz fahren denke ich.
Wenn's relational sein soll, würde ich für so eine simple Sache auf SQlite setzen.
Wenn's relational sein soll, würde ich für so eine simple Sache auf SQlite setzen.
encoding_kapiert = all(verstehen(lesen(info)) for info in (Leonidas Folien, Blog, Folien & Text inkl. Python3, utf-8 everywhere))
assert encoding_kapiert
assert encoding_kapiert
- Hyperion
- Moderator
- Beiträge: 7478
- Registriert: Freitag 4. August 2006, 14:56
- Wohnort: Hamburg
- Kontaktdaten:
Es ist kein Server-Prozess notwendig, sondern alle Daten liegen in einer Datei und werden on-the-fly von der Logik des Datenbanktreibers herausgesucht. Kann man somit überall leicht lokal testen und auch einfachst deployen. Der Firefox nutzt z.B. SQLite zum SPeichern interner Parameter und der Lesezeichen.pole23 hat geschrieben:was genau wäre denn de Vorteil von SQlite?
Ähnliches gibt es auch für NoSQL-Systeme. Tokyo Cabinet iirc.
encoding_kapiert = all(verstehen(lesen(info)) for info in (Leonidas Folien, Blog, Folien & Text inkl. Python3, utf-8 everywhere))
assert encoding_kapiert
assert encoding_kapiert
- noisefloor
- User
- Beiträge: 3856
- Registriert: Mittwoch 17. Oktober 2007, 21:40
- Wohnort: WW
- Kontaktdaten:
Hallo,
wenn du immer "nur" die Suche "zeigt mir zur IP die Daten x und y und z" hast, dann geht auch eine dokument-orientierte DB oder ein KV-Store.
Echte Vorteile bringt das aber IMHO nicht - ich gehe davon aus, dass dass du nur ein paar Dutzend Datensätze hast.
Eine dokumentenorientierte DB hätte vielleicht den Vorteil, dass du in einem Dokument (=Datensatz) auch alle anderen Daten zum Kunden (Tel.Nr., Kontakt etc.) nach belieben speichern kannst.
Wenn es relational sein soll: Der klare Vorteil von SQLite ist die Portierbarkeit (ist in Python integriert) und die "Leichtgewichtigkeit". Für eine paar Dutzend Datensätze braucht man kein Schwergewicht a la MySQL oder PostgreSQL. Und wenn doch (mal irgendwan): der Umzug von SQLite -> MySQL (PostgreSQL) ist ziemlich einfach.
BTW: Das iPhone nutzt AFAIK auch SQLite als DB - wenn wir schon beim Namedropping sind.
Gruß, noisefloor
wenn du immer "nur" die Suche "zeigt mir zur IP die Daten x und y und z" hast, dann geht auch eine dokument-orientierte DB oder ein KV-Store.
Echte Vorteile bringt das aber IMHO nicht - ich gehe davon aus, dass dass du nur ein paar Dutzend Datensätze hast.
Eine dokumentenorientierte DB hätte vielleicht den Vorteil, dass du in einem Dokument (=Datensatz) auch alle anderen Daten zum Kunden (Tel.Nr., Kontakt etc.) nach belieben speichern kannst.
Wenn es relational sein soll: Der klare Vorteil von SQLite ist die Portierbarkeit (ist in Python integriert) und die "Leichtgewichtigkeit". Für eine paar Dutzend Datensätze braucht man kein Schwergewicht a la MySQL oder PostgreSQL. Und wenn doch (mal irgendwan): der Umzug von SQLite -> MySQL (PostgreSQL) ist ziemlich einfach.
BTW: Das iPhone nutzt AFAIK auch SQLite als DB - wenn wir schon beim Namedropping sind.
Gruß, noisefloor