Thema CSV (Comma separated Values) hatten wir schon… Ich hab kein Out-„Lock“ und werds mir auch nicht auf die Platte tun. Wenn ihr mich ordentlich mit Infos füttert (Beispieldateien und so Weiter) bring ich sowas mit rein. Aber wie gesagt SLP - Also in Version 1.1 oder so.
Danke trotzdem für den Hinweis.
Toni
Mal ne Frage an Paresy ( hoffe du liest mit 
) und alle, die sich dafür interessieren…
Es kommen so allerhand Daten zusammen, die auf die Festplatte geschrieben werden wollen. Termine, TerminTyp, Datum, Zeit, Bezeichnung, Scriptname und ein paar Steuerdaten.
Wo sollte ich die speichern? Sollen die alle in die settings.xml oder doch lieber extern in ne CSV (wegen Excel) oder termine.xml oder sowas. Könnte mir vorstellen, dass das die settings.xml unnötig aufbläst. Oder wär das egal? Dann Hauptverzeichnis oder lieber anderswo?
Toni
Hallo Toni,
also mit Sicherheit nicht in die Settings.xml, Deine Daten haben nichts mit der IPS Grundfunktionalitaet zu tun. Lege doch einfach eine kalender.xml neu fuer Dein Modul an. Bitte auch keine CSV - nicht jeder arbeitet mit Excel. Wenn das jemand im Excel weiter verwenden moechte, dann gehoert da ein Export nach CSV ins Modul - damit laesst es sich aber auch in anderen DBs weiter verwenden. Oder man nutzt gleich einen XML Import.
Gruss Torro
Du bringst mich da auf ne idee…
Paradox wäre ne Alternative, oder? Würd mir ne Menge Arbeit bei der Verwaltung und Sortierung sparen und u.U. dadurch grade bei großen Datenmengen einen Geschwindigkeitsboni mit sich bringen…
Müsste dann natürlich so gestrickt sein, dass man auch als unbedarfter User keinen Stress damit hat…
Paradox ist eine Art Mini-Datenbank
Toni
Naja, Wie mans nimmt. Wenn das Kalendarium in Form eines Moduls ein Teil von IPS wird, macht es keinen Unterschied ob ein Script zum 1.5. 16:00 Uhr ausgeführt wird (Kalendarium) oder jeden Montag (per Timer). Und die Daten stehen auch im der settings, oder?
Aber du hast Recht… Mit der Zeit würden sich dort elende Datenmengen ansammeln, wenn man nicht regelmäßig alte Daten rauslöscht…
Hallo Toni,
nee, bitte keine Paradox DB. Wenn Du schon eine Datenbank benutzen willst, dann implementiere auf Windows Seite SQLLite. Damit haben wir dann zusaetzlich auch noch per PHP Zugriff drauf, SQLLite ist naemlich standard in PHP seit Version 5.x. Ich werde irgendwann im WIIPS auch noch SQLLite reinnehmen, um dem User die Datenspeicherung beliebiger Werte noch einfachst zu ermoeglichen.
Gruss Torro
Hallo Toni,
nicht ganz. Die Timer Events werden mit IPS eigenen Funktionen gesetzt. Der Kalender wird aber mit den Modul-eigenen Befehlen gefuellt und bearbeitet, also ist das schonmal grundsaetzlich nicht das gleiche.
Und Dein letzter Absatz ist eigentlich auch das entscheidende. Du darfst auch nicht vergessen, dass die Settings.xml jede Minute geschrieben wird von IPS - willst Du das dann fuer die Mega-Kalenderdaten auch ? Mit Sicherheit nicht.
Gruss Torro
Werd mich mal mit SQLLite auseinandersetzen. Schließlich wollen wir ja alle an dem gleichen Strang ziehen, gell? Aber ansich hatte ich mich schon dagegen entschieden…
Hallo Toni,
warum? Gibts da einen besonderen Grund? Ich wuerde ja lieber mySQL nehmen, aber das ist ja auch wieder Overkill …
Gruss Torro
Hallo,
ist die Anbindung einer Datenbank in PHP so sehr datenbankspezifisch, dass ich mich für eine entscheiden muss?
In den Softwareprojekten, in denen ich beruflich arbeite lösen wir das normalerweise durch ein Datenbankmodul, das ein allgemeines Interface für die Anwendung bietet und dann eine datenbankspezifische Implementierung macht. Dadurch ist die Anwendung relativ unabhängig vom Datenbankhersteller.
Würde hier so etwas nicht Sinn machen? Ich denke, dass mit SQL92 alles abgedeckt sein sollte, was das Kalendarium benötigt.
Wer hat schon MySQL laufen hat, kann die nutzen. Und wer möchte kann SQLLite oder was anderes nutzen. Bei ausgefallenen Sachen muss er halt noch das Datenbankinterface implementieren.
Gruß,
Jörn
Naja… Die entscheidung fällt relativ leicht, wenn man bedenkt, dass MySQL quasi von selbst läuft und vieles andere erst eingebungen und eingerichtet werden.
Aber PHP hat bei dem Kalendarium nur eine untergeordnete Rolle. Aber wenn wir die Geschichte etwas weiter spinnen, dann wäre es doch schön, wenn man seine Termine auch gleich im WIIPS anzeigen und verwalten könnte. Eine gemeinsame Datenbank würde dies schon vereinfachen.
Desweiteren könnte man IPS-Werte in dieser zentralen Datenbank fürs Torros RRD-Tooll speichern oder Wetterdaten archivieren u.s.w.
Da ist die Wahl der Datenbank schon nicht ganz unwichtig. Sie sollte einfach zu programmieren, warten und für den Enduser einfach zu gebrauchen sein. Und vor allem: Sie sollte Kostenlos sein.
Toni
Hallo Joerg,
ja, da es fuer jede Datenbank der entsprechenden Treiber bedarf. (Clients) Und bei PHP 5.x ist nur SQLLite standardmaessig (also bereits im Kern) enthalten. Man braucht keine zusaetzliche Serversoftware wie bei mySQL, PG, SAPDB usw. - das spart einiges an Installations- und Administrationsaufwand beim User.
In den Softwareprojekten, in denen ich beruflich arbeite lösen wir das normalerweise durch ein Datenbankmodul, das ein allgemeines Interface für die Anwendung bietet und dann eine datenbankspezifische Implementierung macht. Dadurch ist die Anwendung relativ unabhängig vom Datenbankhersteller.
das hat damit ja nichts zu tun. Trotzdem benoetigst Du noch dle Clientbibliothek, auf der diese Implementierung aufbaut. Und natuerlich auch den Datenbankserver. Beides spart man sich bei SQLLite.
Würde hier so etwas nicht Sinn machen? Ich denke, dass mit SQL92 alles abgedeckt sein sollte, was das Kalendarium benötigt.
Wer hat schon MySQL laufen hat, kann die nutzen. Und wer möchte kann SQLLite oder was anderes nutzen. Bei ausgefallenen Sachen muss er halt noch das Datenbankinterface implementieren.
Gruß,
Jörn
es geht hier ja um ein IPS Modul, nicht um eine Anwendung, die separat laufen soll. Und als Nebeneffekt finde ich es sehr vorteilhaft, wenn man mit dem vorhandenen (PHP) auch direkt auf diese Daten zugreifen kann, ohne dass man weitere Software noch installieren muss. Und wer bereits mySQL benutzt oder SAPDB oder PG - Toni kann nicht in seinem Modul fuer jede Clientbibliothek die entsprechenden Implementierungen durchfuehren, ist ja schliesslich nur nebenbei…
Gruss Torro
PS: Fuer alle, die jetzt mit SAPDB nix anfangen koennen: Das benutzen wir, wenn es um transaktionsrelevante Daten geht, da ist uns mySQL zu unsicher.
Jörn 
Aber nicht so schlimm, passiert ständig.
ja, da es fuer jede Datenbank der entsprechenden Treiber bedarf. (Clients) Und bei PHP 5.x ist nur SQLLite standardmaessig (also bereits im Kern) enthalten. Man braucht keine zusaetzliche Serversoftware wie bei mySQL, PG, SAPDB usw. - das spart einiges an Installations- und Administrationsaufwand beim User.
Das war mir schon klar. Da wäre mein Standpunkt, dass das dann jeder selber wissen muss, was die verschiedenen DBs für Vor- und Nachteile haben.
das hat damit ja nichts zu tun. Trotzdem benoetigst Du noch dle Clientbibliothek, auf der diese Implementierung aufbaut. Und natuerlich auch den Datenbankserver. Beides spart man sich bei SQLLite.
Auch klar.
es geht hier ja um ein IPS Modul, nicht um eine Anwendung, die separat laufen soll. Und als Nebeneffekt finde ich es sehr vorteilhaft, wenn man mit dem vorhandenen (PHP) auch direkt auf diese Daten zugreifen kann, ohne dass man weitere Software noch installieren muss. Und wer bereits mySQL benutzt oder SAPDB oder PG -
Jeder wie er mag.
Toni kann nicht in seinem Modul fuer jede Clientbibliothek die entsprechenden Implementierungen durchfuehren, ist ja schliesslich nur nebenbei…
Ich meinte damit
dass sich dann jeder selber kümmern müsste, wenn er was anderen haben wollte, als die vorhanden Interfaces. Ich will Toni nicht den Spass am Hobby verderben. :rolleyes:
Standard wäre dann z.B. SQLLite oder MySQL. Wer dann PG haben will muss das selber anbinden. Aber für die Anwendung ( aus Sicht der DB ist es egal ob der DB-Client Anwendung oder Modul einer Anwendung ist) wäre es egal welche DB darunter liegt.
Gruß,
Jörn
Das ist es ja… Die allermeissten IPS-User wissen nicht mal was ein DBMS ist - geschweige denn welches man nimmt oder wo man eins bekommt. Für diese User ist das alles gedacht und für die (und uns selbst natürlich) machen wir uns die Arbeit.
Wer Ahnung hat, schreibt sich schnell mal ein Interface selbst. Gibt genug User (fällt grad kein name ein, sry) die schon mit MySQL Daten archivieren. Kann man alles machen.
Der verdient seine Brötchen damit und genau darum darf das nicht so aufwendig werden. 3-Schicht-Modell, Schnittstellen ausdenken, Szenarien vorherahnen… Wer den ganzen Tag proggt hat Abends halt nicht mehr so viel Lust dazu… Und im Sommer schon gleich garnicht
Toni
Hallo Joern,
muss ja nicht sein, sorry. Wo kommt der Name eigentlich her? Hhm, Mist, ist ja Off-Topic 
dass sich dann jeder selber kümmern müsste, wenn er was anderen haben wollte, als die vorhanden Interfaces. Ich will Toni nicht den Spass am Hobby verderben. :rolleyes:
Standard wäre dann z.B. SQLLite oder MySQL. Wer dann PG haben will muss das selber anbinden. Aber für die Anwendung ( aus Sicht der DB ist es egal ob der DB-Client Anwendung oder Modul einer Anwendung ist) wäre es egal welche DB darunter liegt.
Gruß,
Jörn
naja, so einfach ist es nicht. Die Datenbanken haben ja verschiedene Strukturen, und hier muss sich Toni festlegen, wenn er ein IPS-Modul macht. Er kann ja nicht ein mySQL basierendes Modul machen und Du willst aber die Datenbank als PG haben. Wie soll das funktionieren? Du kannst ja nicht in den Modul Code eingreifen. Wir sprechen hier nicht von PHP.
Also nochmal: Toni programmiert ein Fertig IPS Modul mit einer Datenablage, die als SQLLite strukturiert ist. Auf diese kannst Du dann mittels PHP und integrierter SQLLite Clientbibliothek drauf zugreifen. Du kannst auch saemtliche Anwendersoft verwenden, die auf SQLLite DBs zugreifen kann. Du kannst aber nicht mit einer mySQL Clientbibliothek darauf zugreifen, macht ja auch keinen Sinn. Andersherum kannst Du auch keine mySQL als Datenbank verwenden, weil Tonis Code keine mySQL Clientbibliothek beinhaltet. Das meinte ich damit, dass er nicht alles beruecksichtigen kann und auch nicht soll, dazu waere dass dann viel zu umfangreich und ueberdimensioniert. Und ein weiterer Gedanke steckt noch dahinter: Bei mySQL oder PG Implementation waere jeder User dazu gezwungen, den entsprechenden Server zusaetzlich auf dem IPS Server zu installieren. Fuer die Anwendung des Moduls waere dass dann Pflicht. Und genau das wollen wir vermeiden, umsoweniger zusaetzlich installiert werden muss, je einfacher ist es fuer den Anwender. Und wir wissen alle, dass es eh nicht einfach ist, eine komplexe Hausautomation zu implementieren.
Gruss Torro
Ja, Torro hats auf den Punkt gebracht. Es soll halt möglichst keine Installationsroutine und kein setup, keine wilden Einstellorgien notwendig sein.
@Torro:
Du warst schon aus dem Chat raus… Ich hab ne Lösung für den Wrapper. Funzt gut mit ner 3er version. Ich bleib aber vorerst trotzdem noch skeptisch
Nu ist aber erstmal Feierabend…
Toni
OT: Soweit ich weiß aus dem skandinavischen. Abgeleitet von Björn.
Ich hab mal kurz ein kleines Architektur Diagramm gemacht.
In der „Execution Logic Layer“ (ELL) ist die gesamte Logik mit allen SQL Statements (SQL92) um die notwendigen Tabellen anzulegen und zum Daten reinschreiben und lesen.
Die „Database Access Layer“ (DAL) stellt der ELL Funktionen zum Öffnen und Schließen der Datenbankverbindung und zum Ausführen von SQL zur Verfügung.
Über die Konfigdaten lege ich fest, welche Datenbank ich verwenden möchte. Darüber kann die DAL entscheiden, auf welchen Connector sie zugreifen muss.
Der Connector muss die Funktionen der DAL nun datenbankspezifisch umsetzen. Als z.B. OpenConnection() auf OpenConnectionSQLLite(), usw.
Toni könnte jetzt z.B. nur den „SQLLite Connector“ umsetzen und legt damit fest, wie die API der DAL für Connectoren aussieht.
Wenn ich MySQL einsetzen möchte. Muss ich einen „MySQL Connector“ schreiben.
Damit würde der Mehraufwand nur in der Definition der DAL liegen. Würde dafür aber die Flexibilität bekommen alle Datenbank ansprechen zu können, die mit PHP ansprechbar sind.
Ich hoffe meine Idee ist damit etwas klarer geworden.
Ich könnte mir vorstellen, dass solche Modelle bereits in verschiedene PHP OpenSource Projekte umgesetzt wurden. Danach müsste ich aber erst mal suchen.
Ich habe auch schon überlegt, dafür ODBC zu nutzen. Die ODBC-Treiber werden normalerweise vom Datenbank-Hersteller mitgeliefert. Aber ODBC hat manchmal mit der Performance so seine Schwierigkeiten.
Gruß,
Jörn
Hallo Joern,
ich habe von Anfang an verstanden, was Du willst. Aber Du gehst hier davon aus, dass Toni etwas in PHP macht. Dem ist nicht so, das IPS Modul wird nativ als DLL bereitgestellt.
Ich könnte mir vorstellen, dass solche Modelle bereits in verschiedene PHP OpenSource Projekte umgesetzt wurden. Danach müsste ich aber erst mal suchen.
Ich habe auch schon überlegt, dafür ODBC zu nutzen. Die ODBC-Treiber werden normalerweise vom Datenbank-Hersteller mitgeliefert. Aber ODBC hat manchmal mit der Performance so seine Schwierigkeiten.
Gruß,
Jörn
in PHP gibts da einiges, wir haben in der Firma z.B. uns einen eigenen Abstraktionslayer geschrieben und greifen so auf mySQL und SAPDB gleichzeitig zu, egal welche DBs gerade dran ist.
Aber mit ODBC gehts schon los - muss separat installiert werden durch den Anwender, sonst kannste es nicht nutzen.
Ich weiss, worauf Du hinaus willst. Wenn ich fuer mich etwas machen wuerde, haette ich zum Beispiel auch das eine oder andere gleich mit mySQL gemacht - ABER - wir muessen hier User mit Anwendungen erfreuen, die keinerlei Ahnung von zusaetzlichen Software-Anwendungen haben, die sie erst installieren und konfigurieren muessen.
Eine ausgewaehlter Kreis der User, ich will mal keine Namen konkret nennen, haben mit Sicherheit kein Problem, das eine oder andere zu machen, aber genau fuer diese soll die Softwareloesung eben nicht sein.
Gruss Torro
Das war mir wiederum nicht klar.
Und bei PHP 5.x ist nur SQLLite standardmaessig (also bereits im Kern) enthalten.
Ich hab mich dann davon wohl etwas ablenken lassen und folgendes übersehen:
Ok, ich kauf den Punkt, dass das Ganze für den normalen Endanwender möglichst einfach und unkompliziert sein soll. Usability first!
Aber für „Advanced“ Users wäre es schon gut auch andere Datenbank anbinden zu können.
Die Architektur der Datenbankanbindung ist ja unabhängig von der Programmiersprache umsetzbar. Es würde nur ein klein wenig aufwändiger für anderen weitere Datenbank-Connectoren zu erstellen. Die müssten dann halt als DLL ein von euch festgelegtes API implementieren.
Aber unabhängig davon möchte ich die Diskussion nicht weiter unnötig in die Länge ziehen.
Mein Fazit:
Wenn sowas machbar wäre, wäre es toll. Wenn nicht, ist das auch kein Beinbruch. War nur ein Vorschlag.
Gruß,
Jörn
Das ist ein Klassisches 3-Schichten-Modell, dass du oben angehängt hast. Aber der Mehraufwand liegt halt nicht nur in der DAL sondern auch darin die Schnittstellen zu definieren und umzusetzen.
Ich würde also eine Schnittstelle zu IPS in einer DLL brauchen, die mir das fetching der Variablen ermöglicht. Dann die eigentliche Programm-Oberfläche, die wegen der Anbindung zu IPS sinnvollerweise ebenfalls in eine DLL kompiliert wird oder mit der IPS-Schnitstelle zusammen in Einer. Dann Dein DB-Access-Layer in einer eigenen DLL und die Austauschbarkeit zu ermöglichen. Dann der Datenbanktreiber in Abhängigkeit zum DBMS und ggf eine Steuer oder Interface Schnittstelle wie DBExpress (Umstritten, aber ich arbeite gern damit) in einer Weiteren DLL. Da jede DLL mit der höheren un der niedrigeren kommuniziern muss braucht man allerhand Schnitstellen, die man sich ersteinmal ausdenken, implementieren und testen muss ( sollte ). Dazu die eigentliche Datenbankinstallation.
Unterm Strich:
[ul]
[li]IPS-Schnittstellen DLL (passend zur IPS Version)[/li][li]Application-Layer DLL (Meine Entwicklung)[/li][li]DB-Access-Layer DLL (Passend zur Datenbanktreiber DLL)[/li][li]Datenbanktreiber DLL (passend zur DB deiner Wahl)[/li][li]Interface DLL (Abhängig von der DB-Access-Layer DLL)[/li][li]Kalendarium-Setup - Blickt ja sonst niemand mehr durch[/li][li]Datenbank-Setup[/li][/ul]
Dem unbedarftem User möchte ich das ersparen sich da durch zu quälen. Und wenn er sich aus unwissenheit eine falsche DLL aus dem Netz läd läuft garnix. Ich würd das nun alles in einer DLL verpacken und einen embedded Server (keine installation) dazulegen, der von vorn herein von PHP unterstützt wird. So ist (vorerst) der Plan. Zwei Dateien und die Application-Area bleibt IPS, auf das direkt ja nur paresy Einfluss hat.
Die Idee ist gut, ich arbeite beruflich nach diesem Schema, aber ich denke nicht, dass ich das hier umsetzen werde. Der Aufwand steht einfach in keinem Verhältnis zum Nutzen. Ich möchte aber auch nicht ausschließen, dass ich Torro mal zu Firebird oder embedded Firebird überredet bekomme
Dann könnte man wirklich eine (aber eben nur EINE) Datenbank hinter IPS legen. Aber dem müsste dann ein großes Konzept vorausgehen, dass auch paresys Entwicklungen betrifft, da diese dann sinnigerweise auch die Settings.xml und Wetterdaten und, und, und aufnimmt.
Aber das ist jetzt nur ein Hirngespinst von mir.
Toni