Ich überlege ob man in der Firma wo ich arbeite nicht vielleicht Python als Skriptsprache nehmen könnte. Im wesentlichen haben wir Datenbanken mit 1000-100000 Objekten und wir analysieren die Verlinkungen zwischen den Objekten. So ein bisschen wie Google bloß nicht so groß
Was würdet ihr für eine Umsetzung empfehlen?
Also ein Python ORM wie SqlAlchemy oder eine C++ Lösung auf die man connected? Wie würde man da eigentlich sowas kombinieren?
Und gibt es ein professionelles IDE, das auch Arbeit mit Datenbanken vereinfacht und zum Beispiel SQL Tabellen schnell mal anzeigen kann?
Vielleicht noch ein Tipp welche Datenbank man nehmen soll? Bis jetzt haben wir wohl MySQL.
Naja, je nach Datenstruktur könnte man auch einen Blick auf alternative NoSQL - Systeme werfen (mongodc, couchdb, usw.). Ansonsten wäre Postgres sicherlich immer eine lohnenswerte Alternative. Bei den Werten ggf. auch SQLite.
Was wollt ihr denn genau analysieren? C++ könnte mehr Geschwindigkeit bieten - allerdings kann da auch das IO die Bremse sein, nicht der Algo zur Analyse. Insofern kann man schwerlich allg. Tipps geben.
Ich würde vielleicht gar nicht so sehr von MySQL weg tendieren, aber dachte auch ob man nicht MS SQL Server oder so nimmt. Aber das ist noch das kleinste Problem.
Ich muss irgendwie überzeugen, dass man mit Python und Datenbanken gut arbeiten kann. Das frage ich mich mehr, welche Libraries genau ich nutzen sollte (ohne auf rohes SQL zuzugreifen) und ob es brauchbar ist einen C++ ORM zu verwenden und zu erweitern. Und eben wie man mit Datenbanken arbeitet und debuggt. Also schnell mal paar Tabellen anschaut und bei Bedarf manuell editiert zum Testen.
Ich dachte an Python weil wir projektorientiert arbeiten und oft auf die Schnelle mal neue Prototypen von Scoring-Algorithmen programmieren müssen.
Im wesentlich bewerten wir Objekte anhand von Links zwischen ihnen. Das heißt wir haben eine Objekttabelle mit IDs und Eigenschaften und eine Link Tabelle die sagt was verbunden ist. Daraus berechnen wir wie "wichtig" das Objekt ist. Der derzeitige Algorithmus ist mathematisch trivial und besteht ein wenigen JOINs und Aggregationen. Schwieriger ist die ganze Infrastruktur, da wir Daten zwischen Abteilungen austauschen müssen und wie gesagt ad hoc Flexibilität im Algorithmus brauchen.
eine weitere Frage ist: brauchst du in der DB nur die Rohdaten und die Algorithmen laufen programmseitig? Dann fährst du mit einer relationalen DB + Python nicht schlecht. Ein Vorteil von Python ist hier übrigens die einheitliche Schnittstelle (Python DB API 2.0). Dadurch kannst du dein Programm super einfach auf eine andere DB anpassen, du musst nur 2 Zeilen anpassen (das import-Statement für das DB-Modul) und ggf. die Parameter des connect-Befehls).
Wenn du die Beziehung inkl. Gewichtung direkt in der DB speichern möchtest, dann wirf mal einen Blick auf GraphDBs. Die sind u.a, für so was gemacht. Praktische Erfahrung habe ich selber damit aber keine.
An sich kommen wir bis jetzt wirklich nur mit Rohdaten aus. Die Algorithmen sollen am Ende sowieso nur in Python sein, weil die je nach Projekte immermal anders sind. Ich schau nochmal wegen Python DB API.
Wobei die beinhaltet nicht ORM Methoden? Und wie ist mit Schemata?
Ich muss ja eine Methode finden wie man den SQL Umgang vereinfacht und vorbereitet.
@Gerenuk: Die Python-DB-API stellt nur die grundlegende Verbindung zur Datenbank zur Verfügung. Zur Vereinfachung des Umgangs mit SQL-Ausdrücken gibt es dann SQLAlchemy. Diese Bibliothek ist im Übrigen glücklicherweise mehr als einfach nur ein ORM, sondern vereinfacht insbesondere auch die Erzeugung und Manipulation von SQL Ausdrücken, so dass man nicht mehr mit Zeichenketten umher hantieren muss. Ein ORM ist nicht immer das Mittel der Wahl, so aber ist SQLAlchemy eigentlich ein universales Datenbankwerkzeug.
Arbeite einfach einmal die Tutorien aus der SQLAlchemy-Dokumentation durch (und zwar alle, nicht nur das über die ORM-Schicht), dann erhältst Du einen recht guten Einblick in die Möglichkeiten von SQLAlchemy und kannst anschließend selbst beurteilen, ob es für Dein Projekt geeignet ist.
OK, cool. Also ist die einzige ernsthafte Möglichkeit SQLAlchemy?
Wie ist da eigentlich die Lizenz? Wir verkaufen nicht unsere Programme, aber sehr wohl die Daten die da rauskommen.
Wie sieht es mit C++ SQL-Library Lösungen aus zu denen man verbindet?
Und welches Programm benutzt ihr um mal schnell in DBs zum debuggen reinzuschauen?
@Gerenuk: Ich habe nicht gesagt, dass SQLAlchemy die einzige ernsthafte Möglichkeit ist. Es gibt viele Datenbank-Bibliothek für Python, nicht zuletzt auch in Anbindungen an GUI-Toolkits (e.g. QtSql), deren Einsatz je nach Problem und Umgebung möglicherweise sinnvoller ist als der von SQLAlchemy, obwohl SQLAlchemy mit das beste ist, was man für die Arbeit mit Datenbanken bekommen kann.
Dein Problem und Deine Umgebung kennt niemand besser als Du, wie sollte ich also beurteilen können, ob SQLAlchemy für Dich die einzige Möglichkeit ist, wenn Du das nicht einmal selbst beurteilen kannst (zumal die gegebenen Informationen über Allgemeinplätze kaum hinausgehen)? Du musst schon selbst wissen, wie Dein Problem zu lösen ist, andere können Dir allenfalls verschiedene die Möglichkeiten dazu aufzeigen.
Im Übrigen schadet es auch nicht, einmal selbst zu recherchieren, denn ich fühle mich sicher nicht dazu berufen, Dir die Lizenz von SQLAlchemy vorzulesen.
Mit C++ und Datenbanken kenne ich mich nicht aus. Wieso aber willst Du unbedingt C++ ins Spiel bringen, wenn die Logik offenbar vollständig in Python implementiert wird?! Welche Vorteile erhoffst Du Dir denn davon?
Zum Blick in die Datenbank benutze ich meist die Datenbankkonsole. Für MySQL und Postgre gibt es mit MySQL Workbench bzw. pgadmin relativ umfangreiche GUI-Programme zur Abfrage und zur Administration einer Datenbank. Für SQLite gibt es eine relativ umfangreiche Firefox-Erweiterungen, deren Name mir entfallen ist, und diverse, eher mittelprächtige GUI-Programme. Mit anderen DBMS kenne ich mich in dieser Hinsicht nicht aus.
Natürlich überlege ich am Ende selbst was am besten passt. Deswegen suchte ich halt nur nach Vorschlägen. Ich erwarte von keinem, dass er mir garantiert was das beste ist, so dass ich es blind übernehme. Und es muss natürlich auch keiner Lizenzen für mich nachschlagen. Deswegen fragt ich ja in die Runde ob nicht zufällig schon jemand die Quintessenz kennt.
Danke für die Vorschläge zur DB Arbeit. Ich schau sie mir mal an.
Wegen C++ habe ich nachgedacht, weil vielleicht mal der eine oder andere Standardbefehl schnell sein soll. Wenn die DB z.B. irgendeine spezielle Operation oder Funktion nicht unterstützt, die ich aber performant braucht. Im einfachsten Fall sowas wie Pivotieren.
@Gerenuk: Über mögliche Probleme mit der Ausführungsgeschwindigkeit kannst Du nachdenken, wenn Du welche hast. Dann kannst Du kritische Teile immer noch nach C auslagern oder als Stored Procedure implementieren.
Wobei SQAlchemy mit Sicherheit am populärsten ist.
Wegen C++ habe ich nachgedacht, weil vielleicht mal der eine oder andere Standardbefehl schnell sein soll. Wenn die DB z.B. irgendeine spezielle Operation oder Funktion nicht unterstützt, die ich aber performant braucht. Im einfachsten Fall sowas wie Pivotieren.]
Je nach dem, wie komplex dein Queries sind und wie groß das Ergebnis ist, warten dein Programm so oder so mehr auf die DB als selber zu rechnen. Daher: erst mal programmieren, dann optimieren.
Danke für die weiteren Vorschläge. Spricht irgendwas gegen SQLAlchemy und für eines von Autumn, SQLObject oder Storm? Internetrecherchen schien zu ergeben, dass SQLObject nicht so doll ist und Autumn ist ja eher super-lightweight. Und im gefundenen Vergleich von Storm und SQLAlchemy sah ich keine Vorteile von Storm?!
Apropos eigene Funktionen: Eine sehr wichtige Grundfunktion bei ist das Pivotisieren. Also speziell
1 a x
1 b y
2 a q
2 b w
->
a b
1 x y
2 q w
T-SQL von MS SQL Server kann das wohl, aber nicht die üblichen SQLs? Notlösungen die ich fand waren höchstens CASE Abfragen die die Variablen erst filtern und dann mit SUM aggregieren.
Geht das noch irgendwie anders?
Gerenuk hat geschrieben:Danke für die weiteren Vorschläge. Spricht irgendwas gegen SQLAlchemy und für eines von Autumn, SQLObject oder Storm? Internetrecherchen schien zu ergeben, dass SQLObject nicht so doll ist und Autumn ist ja eher super-lightweight. Und im gefundenen Vergleich von Storm und SQLAlchemy sah ich keine Vorteile von Storm?!
Apropos eigene Funktionen: Eine sehr wichtige Grundfunktion bei ist das Pivotisieren. Also speziell
1 a x
1 b y
2 a q
2 b w
->
a b
1 x y
2 q w
T-SQL von MS SQL Server kann das wohl, aber nicht die üblichen SQLs? Notlösungen die ich fand waren höchstens CASE Abfragen die die Variablen erst filtern und dann mit SUM aggregieren.
Geht das noch irgendwie anders?
Bei Postgres kann man dazu die tablefunctions benutzen, die sind im contrib-Verzeichnis zu finden und müssen extra installiert werden. Vielleicht reicht das für deine Anwendung. In Kombination mit Windowfunctions (>8.4) kann man da nette Sachen mit machen, sind aber doc eingeschränkt.
Gruß Uwe
---------------------------------
have a lot of fun!
Gerenuk hat geschrieben:Geht das noch irgendwie anders?
Ja, grundsätzlich schon. Du hast ja immer zwei Möglichkeiten: Die Programmlogik in die DB zu legen, oder die Programmlogik in Python zu implementieren und aus der DB die "Rohdaten" zu ziehen.
Letzter Möglichkeit kann "aufwendiger" sein, macht dein Programm aber universeller, da du nicht an einer speziellen DB und deren Funktionen hängst. Wenn die Wahl der DB aber langfristig fix ist, dann kann (sollte?) man sicherlich auch alle Möglichkeiten der DB nutzen.
Gerenuk hat geschrieben:OK, cool. Also ist die einzige ernsthafte Möglichkeit SQLAlchemy?
Wie ist da eigentlich die Lizenz? Wir verkaufen nicht unsere Programme, aber sehr wohl die Daten die da rauskommen.
Das hat mit der Lizenz des verwendeten Programmes doch nichts zu tun. Außerdem darf alle Freie Software sehr wohl verkauft werden. Auch wenn manche Anbieter leider versuchen, da Verwirrung zu stiften.
Diese würde ich dann aber nicht als frei ansehen. Zugegeben, diese Sache mit der Doppellizensierung wie sie etwa MySQL AB gemacht hat finde ich etwas seltsam.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
