none
Datenbanken

    Frage

  • Hallo VFPler,

    ich hab mal ne ganz andere Anfrage.

    Es geht um eine Systemumstellung und dabei gehts schon bei den Füssen los. Diskussionen um die Programmierumgebung, DB-Umgebung usw. U.a. steht zur Diskussion eine Delphi-Programmierung und als DB Firebird.

    Dazu an dieser Stelle die  Frage: hat jemand schon Erfahrung mit dem Firebird. Taucht das was? kann der Fux und dieser Vogel oder ist es ihm egal ob SQL-Server oder so einer ?
    Das Ganze wäre dann alternativ zum SQL-Server zu sehen.

    Oder was gibt' s sonst an Erfahrungswerten (wenn überhaupt) und Meinungen zu diesem Thema ?

    (weil man ja neben Gans-verdauen sonst über Weihnachten nix zu tun hat
    - nein ganz so schlimm isses noch nicht :-))))

    Grüsse aus dem WBL

    Horst

    Donnerstag, 20. Dezember 2012 08:18

Alle Antworten

  • Neben SQL Server habe ich mit VFP bisher nur MySQL ausgiebiger genutzt, darüber gibt es auch ein Buch bei Hentzenwerke - also über VFP mit MySQL, nicht über meine Erfahrungen damit.

    Radio Eriwan würde auch noch sagen: Im Prinzip Ja.

    Denn alles, was einen ODBC Treiber hat, kann von VFP angesteuert werden. Es gibt aber, wie Du vieleicht weißt, immer mal wieder Berichte über Einzelprobleme, nicht nur mit exotischeren DBs, auch mit MS SQL Server, z.B. beim abholen von VarChar(MAX) Feldern per (älterem?) NativeClient Treiber oder andere Sperenzchen. Und ich lasse jetzt mal Feldtypen und Werte, die sich anderswo nicht 1:1 abbilden lassen außen vor, wie z.B. EMPTY Datum. Überhaupt ist ISBLANK() ein Zustand jeglicher DBF-Feldtypen, den Du in keiner anderen Datenbank so wiederfinden wirst. Aber wenn das wichtig wäre, ist das ein Ausschlusskriterium für alle Datenbanken außer DBC/DBF. Nur ist NULL da sowieso üblicher und vollwertiger, selbst innerhalb VFP.

    Wie gut Firebird mit VFP zusammenarbeitet könnte Dir evtl. Jochen Kirstätter sagen, bestimmt auch einige andere bekannte, aber der fällt mir zum Themenkreis Linux/Open Source noch als erstes ein.

    Google findet ja auch einiges zu "VFP Firebird". Dies hier ist z.B. ein guter Nachweis, dass jemand sich da reingekniet hat: http://www.universalthread.com/ViewPageNewDownload.aspx?ID=32829

    Eine Biliothek, um auch auf Events von Firebird-Datenbanken in VFP reagieren zu können ist schon was fortgeschritteneres in der Nutzung einer DB.

    Tschüß, Olaf.

    Freitag, 21. Dezember 2012 14:04
  • Hallo Horst,

    inzwischen läuft bei uns ja alles auf .net und SQL-Server, die Weiterentwicklung unserer VFP-Pakete haben wir mangels Updates seitens Microsoft eingestellt.

    In der Umstellungsphase haben wir auch interbase, Firebird, MySQL und ein paar andere getestet, unter uns gesagt mit mäßigem Erfolg.

    Aus heutiger Sicht ist ODBC auf Firebird mehr als mühsam.

    Warum?

    1) ODBC ist - sagen wir mal - nicht mehr ganz state of the art, und 64Bit kaum verfügbar, Server gibts aber inzwischen nur noch auf 64Bit

    2) die ODBC-Treiber auf Firebird sind insoferne problematisch, als sie vergleichsweise mühsam zu deployen sind (unterschiedliche Treiber für unterschiedliche Versionen von Betriebssystem und Firebird)

    3) 1998 machten wir einen Vergleichstest von SQL-Server 6.5 gegen interbase 6 als Vorgänger von Firebird. Der Vergleich macht Sie sicher...kein Vergleich! SQL Server läuft seit 1998, beschossen von diversen Webservern mit ca. 300 Requests pro Sekunde quasi "durch" ohne einen einzigen Ausfall (allerdings haben wir mehrere Versionen und mehrere server verbraucht ;-)

    4) der große Vorteil von VFP ist ja die EXE / copy - Deploy-Fähigkeit ohne Installationsroutine, Runtime und Lizenzkosten. Abgesehen von den Lizenzkosten, die anderen beiden Punkte bekommt man mit firebird nciht hin

    5) mit .net aber schon. Im Extremfall kann man mdb's (JET/Access 2000) einbinden, dann gehts sogar auf alten XP-Rechnern (bis .net 4.0) ohne Installation und bei Bedarf sogar direkt von der CD lauffähig, weil JET überall drauf ist (auch ohne Office)

    6) wenns ein bisserl mehr sein darf, den SQL-Server gibts auch kostenlos, den muß man zwar konfigurieren, aber der Zugriff über OLE-DB ist konkurrenzlos gegenüber ODBC

    7) ...und .net rennt halt wirklich überall, mit Mono angeblich sogar auf Linux (ohne gewähr) aber vom Handy (Windows Phone) bis zum Großrechner jedenfalls überall, und immer mit 96% derselben Code-Basis

    Herzliche Grüße an die Gans

    Samstag, 29. Dezember 2012 17:09
  • Ich danke Dir für diese ausführliche Darstellung.
    Damit ist meine Skepsis bestätigt worden und ich werde in dieser Richtung auch nicht mehr
    weiter forschen.Wenn ich an den innovationswütigen Sysop denke und an die diversen BS auf den diversen Servern und lokalen Rechnern (nicht jeder darf ja die neuestens und allerneuesten Sachen haben) und dann von den Treibern lese....

    Mal sehen wie es ausgeht, aber mein Standpunkt hat sich gefestigt.
    Gänseessen ist vorbei.

    Gutes Neues Jahr Dir

    Grüsse aus dem WBL

    Horst

    Mittwoch, 2. Januar 2013 10:12
  • Horst,

    OleDB wird von MS nicht mehr für die Zukunft unterstütz/empfohlen.
    Hier eine Reaktion:
    http://hal2020.com/2011/09/25/ole-db-and-sql-server-history-end-game-and-some-microsoft-dirt/
    ODBC ist das was uralt ist und übrig bleibt.
    mySQL gibt es für 32 + 64 Bit: http://www.mysql.de/downloads/mysql/
    MSSQL Server (alle aktuellen Versionen)  gibt es ebenso für 32 und 64 Bit.
    Aktuelle Firebird Versionen ebenfalls  als 32 + 64 Bit verfügbar: http://www.firebirdsql.org/en/firebird-2-5/

    Grüße Alexander

    Mittwoch, 2. Januar 2013 18:58
  • vielleicht noch ein ganz anderer Ansatz:

    mich hat die letzte dFPUG-Lieferung, die ich in der Weihnachtszeit mal durchgearbeitet hab, gleich 2 kleine Schubse gegeben:

    1. mal wieder an Business Objects zu denken

    2. mir mal NoSQL-Server anzusehen

    Beides passt eigentlich hervoragend zusammen. Tatsächlich immer, sobald ein neues Projekt in Sicht ist, beginne ich schon innerlich mit dem Datenbank-Design und baue darauf letzlich meine ganze Programmier-Strategie auf. Dass dabei das eigentliche Ziel u.U. nicht ganz getroffen wird, merkt man leider selbst nicht. Von vornherein mit Business-Objekten zu arbeiten, ist einfach viel Anwender-näher. Und da kommt dann vielleicht Nr. 2 ins Spiel. Warum muss man sich unbedingt mit all dem Datenbank-Kram abmühen? Was spricht dagegen, einfach die zu speichernden Objekte irgendwo abzulegen und nach Bedarf wiederzuholen, ohne sich um Indexe, Verknüpfungen etc zu kümmern?

    Ich werd auf jeden Fall bei nächster Gelegenheit mal diesen alternativen Ansatz durchprobieren.

    Gruß,

    Winfried

    Mittwoch, 2. Januar 2013 22:22
  • Wiwo,
    noSQL greift dort wo Datenbanken an die Grenzen kommen. Es ist keine Alternative wenn Du eine "Handvoll" Zeilen ablegen willst. 
    Wenn also eines der Argumente für Foxpro hier in diesem Forum lautet das Foxpro beim Eurotunnel mit sehr großen Datenmengen umgehen kann, dann ist es kein Argument für noSQL.
    Der Einarbeitungsaufwand bei noSQL ist sicher größer im Vergleich zur jemanden der sich bereits mit SQL auskennt und von Foxpro zu einem anderen Datenbanksystem wechseln möchte.
    Die Tutorials sind nicht immer einfach und der Service ist eine Frage von "which noSQL".            
    In Business-Objekten zu denken und das in die Datenbank zu packen ist doch für jemanden der Jahrelang Foxpro Erfahrung hat ein alter Hut, dessen Tageswerk.
    Grüße Alexander 

    Donnerstag, 3. Januar 2013 06:43
  • Hallo Jungs,

    jetzt habt ihr mich aber gut angestachelt.Danke für Eure Beteiligung, ist doch immer wieder hilfreich sowas.@Alexander: danke für Deine Links, ist sehr informativ. Ich habe bislang sowieso immer nur die SQL-Passthrough Geschichte genommen - der ODBC Treiber ist mir dabei noch nicht negativ aufgefallen (Meine DB's haben max. so die Größenordnung ca. 100.00 Sätze a 150 Felder (um die 1500 Bytes) um mal ne Hausmarke zu nennen). Ich hatte mit den Treibern für den SQL-Server noch keine Probleme, dachte aber nach der Beschreibung von Inndata das es mit den ODBC-Treibern für die (den?) Firebird problematischer ist.
    @WiWo : Ich muss gestehen das mir noSQL bislang kein Begriff war. Ich lebe wohl zeitweise hinterm Berg hier. Hab natürlich gleich mächtig herumgegoogelt und find das hochinteressant. macht sich da was Neues auf was unter Umständen alternativ sinnvoller ist als eine SQL-DB? Was auch immer: kannst Du mir noch mal kurz näher erläutern wie Du das mit den Business-Objekten meinst. Oder dazu noch einen guten Link geben? d.h. ich würde gern wissen , redest Du hier von speziellen Objekten , die es irgendwo gibt oder eine ganz spezielle Technik die man nachlesen / lernen kann oder meinst Du einfach die Trennung : Screens - DB_Anbindung- Business_Logik und die Objekte die man sich dann danach bastelt.

    Grüsse aus dem tristem grauen Regenschleier

    Horst

    Donnerstag, 3. Januar 2013 16:21
  • Hallo Horst,

    ich hab hier eigentlich meine eigenen guten Vorsätze fürs neue Jahr angesprochen;)

    Die Business-Objekte gehen einen Schritt darüber hinaus, nur eine zusätzliche Schicht zwischen Datenbank und User-Interface zu sein. Vielmehr (und das hab ich in meinen letzten Entwicklungen sträflich vernachlässigt und gelobe Besserung) sind sie vom Ansatz an schon der Kern der Entwicklung. Das könnte heißen, am Beispiel eines Warenwirtschaftsprogramms, ich habe eine Klasse Auftrag, eine Lieferschein, eine Rechnung, eine Mahnung, eine Gutschrift (oder alle 2-fach für eingehend und ausgehend), alle vielleicht abgeleitet von einer Klasse Beleg. Jeder dieser Klassen kümmert sich um alles, was mit ihr verbunden ist. Die Abläufe, wie sie in einem klassischem Bürobetrieb stattfinden, werden hier abgebildet, zunächst ohne sich groß um Datenspeicherung und User-Interface zu kümmern. 

    Die typische Vorgehensweise grad von ausgefuchsten SQL-Server-Entwicklern ist die, für solch eine Aufgabe erst mal ein Daten-Modell zu entwerfen und das als Grundlage des gesamten Projekts zu machen. Und Oberflächen-verliebte Entwickler fangen mit dem User-Interface  an und stricken dann die Funktionalität dran. Ich will mal fürs nächste Projekt den oben beschriebenen Weg mit den Business-Objekten gehen.

    Mit NoSQL-Datenbanken hatte ich mich bislang überhaupt noch nie beschäftigt. Ich hatte nur mal gehört, dass einige der richtig Großen, wie z.B. Facebook, ein NoSQL-Datenbanksystem einsetzen, wusste aber nicht, warum. NoSQL steht übrigens nicht, wie ich dachte, für "kein SQL", sondern für "Not Only SQL". Und der Grund für ihren Einsatz sind wohl nur zum Teil die riesigen Datenmengen; vielmehr machen sie vorallem den Programmierern (und Datenbankverwaltern) das Leben einfacher. Wie sehr, das muss ich aber auch erst rausfinden. Vermutlich wird mein Versuchs-Projekt mit RavenDB arbeiten, damit bin ich allerdings auf VisualStudio festgelegt, mit dem ich seit ein paar Monaten parallel zu VFP arbeite.

    Sollte hier jemand schon mal mit einer NoSQL-DB gearbeitet haben, würden mich seine Erfahrungen interessieren. NoSQL ist allerdings eher keine Alternative zum FoxPro-internen Datenbank-Handling, wohl aber zu einer SQL-Server-Anbindung.

    Gruß,

    Winfried

    Donnerstag, 3. Januar 2013 22:04
  • Hi WiWo,

    dann hoffe ich mal für Dich das die meisten Deiner guten Vorsätze Realität werden.

    Business Objekte : Hört sich alles sehr interessant an, aber ich  habe so meine Zweifel ob sich das in der Reinheit überhaupt so realisieren lässt. Also ich bin da schon ein Oberflächenverliebter wobei ich das Datendesign eigentlich eher parallel mache. Ich habe aber schon länger kein grundlegendes Projekt aus dem Boden gestampft sondern erweitere/ändere hauptsächlich bestehende. Und wenn - dann ist alles individuell. Und hier kann ich im Grunde keinen betrieblichen Ablauf voll abbilden. Theoretisch natürlich, aber die User kommen dann immer mit noch einer Info und noch einem Wunsch und manches auch erst wenn eine Maske steht usw. Also eigentlich immer so eine Art XP(extrem Programming). Das Grundlegendste was ich immer hab sind Daten und deren Strukturen-und da muss ich meistens noch Abteilungsexterne und auch Firmenexterne Strukturen berücktsichtigen. Und dann schält sich ein genauer Ablauf immer erst im Laufe der Entwicklung heraus. Vielleicht mach ich ja auch was falsch.
    NoSQL werd ich mir auch mal angucken. Und wenn Du es schon beschreibst auch die RavenDB.Visual Studio schockt mich nicht :-)), hab ich sowieso. Datenmengen sind bei mir ja auch nicht soo das Thema, aber wenn etwas einfacher (bei gleicher Komplexität wohlgemerkt) geht, na da bin ich doch gerne dabei.
    Hoffe nur das ich dabei nicht wieder zuviel Zeit verbrate um es hinterher doch in die Ecke zu feuern.Foxpro internes Handling muss leider immer mehr weichen.

    Also viel Erfolg
    Horst

    Freitag, 4. Januar 2013 17:00
  • Ohne mich jetzt mit Ruhm bekleckern zu wollen, oder zu können, weil ich das Thema noSQL nur am Rande mitkriege, aber CouchDB oder SQLite adressieren ja wohl gerade nicht big data, sondern im Gegenteil kleine Datenmengen.

    Ich tippe eher nicht darauf, daß hadoop/hdata das ist, was Horst jetzt als Ersatz für VFP/DBF oder Delphi/Firebird braucht. In dem Regime sind wir ja doch eher bei den klassischen RDBMS und SQL.

    Aber prinzipiell ist natürlich die Frage, worum's in dem neuen Auftrag gehen soll, was jetzt die passendste Lösung dafür ist.

    Wenn man auch mit Foxpro auf die Daten will, evtl. auch nur als Admintool, dann sollte es eine ODBC oder OLDB fähige DB sein. http-Requests kann man natürlich auch aus Foxpro heraus machen, ist allerdings nicht mehr so straight forward.

    Und klar ist VFP selbst zu bedenken. Bei Dir sind ja soweit ich verstehe auch größere Delphi-Kenntnisse vorhanden, Horst. Auch nicht gerade ein viel modernerer Ansatz, aber immerhin gibt es Embarcadero Delphi XE3 für Win8, was man von VFP nicht behaupten kann.

    Ich würde mich durachaus weiter hinaus wagen und auch eine DB in Betracht ziehen, die andere für dieselbe Problemstellung schon erfolgreich eingesetzt haben, eine Brücke zum Datenzugriff kriegt man eigentlich immer hin. Alles natürlich wie immer eine Frage von Zeit, Budget und Qualitätsansprüchen, sowie Vorkenntnissen oder Vernetzung mit entsprechenden Experten.

    Tschüß, Olaf.


    Donnerstag, 10. Januar 2013 12:50
  • Huups,
    jetzt bin ich etwas verwirrt. Ist denn noSQL nun für große oder kleine Datenmengen geeignet. Na, ich werds noch rausfinden.
    Delphikenntnisse habe ich Null!
    Die Sache ist die das in einer Firma in bestimmten Bereichen alles neu gestaltet werden soll.Nun gibt es verschiedene Fraktionen die unterschiedliche Zielrichtungen bevorzugen. Die einen wollen alles mit AIX lösen (kenne ich nur vom Namen) und andere halt mit Delphi und "einer DB". Ich bin da kein Entscheidungsträger, werde aber evtl. in eine längere Sache mit eingebunden und werde auch nach meiner Meinung gefragt. Da ich eigentlich meine Anfänger-C#-Kenntnisse ausbauen wollte sollte erst  ein C#/Delphi-Mix erfolgen (;-)) nach dem Motto :Hauptsächlich ist es sowieso alles .Net. (womit die Frage nach der DB natürlich immer noch nicht geklärt wäre.)
    Delphi wurde schon vor Jahren an mich herangetragen aber da stand Delphi zum Verkauf ohne Käufer und das fand ich nicht unbedingt eine zukunftsfrohe Sachlage. Ob das jetzt besser ist ???

    Ob ich jetzt da einsteige ist einfach die Frage wieviel mir das bringt. Wenn jahrelang Brot und Wohlstand - dann mach ich (fast) alles.Die Entscheidung (und damit die Verantwortung) ob es genommen werden sollte mache ich nicht. Mit VFP mag ich da nicht kommen.

    Das ist so der Hintergrund.

    Das nun die info mit noSQL aufkam finde ich einfach über dieses Projekt hinaus interessant. Man muss ja schliesslich Entwicklungen im Auge haben und wenn es sich gut anwenden lässt...

    Zeit und Budget : Ich hab mir schon mit Mühe das Lachen verkneifen müssen. Es kam schon die
    Frage ob wir uns lange mit Analysen aufhalten müssen oder nicht schon mal das  Wichtigste
    programmieren könnten. Manchmal muss man eben sanft Zahnarzt spielen...

    Grüsse aus dem flockigen WBL

    Horst

    Montag, 14. Januar 2013 08:36
  • noSQL Datenbankgröße.

    Das ist genausowenig wie bei klassischen relationalen Datenbanken durch die Zugriffstechnik vorgegeben. Es gibt kleine Datenbanken wie CouchDB und großße wie hadoop/hdata.

    Siehe http://de.wikipedia.org/wiki/NoSQL

    NoSQL ist geschichtlich also über eine Datenbank für kleine Datenmengen entstanden. Und es gibt mindestens mal zwei unterarten von NoSQL im Sinne von no wie nein/kein SQL und no wie Abkürzung für not only SQL.

    In den für ein Großprojekt interessanteren Varianten hat noSQL eher einen noch anderen Aspekt unabhängig von der Art Daten abzufragen, nämlich den Aspekt verteilte Datenbank, kein einzelner zentraler SQL Server.

    Es ist fraglich, ob das in dem Projekt so benötigt wird.

    Welche Datenbank ideal ist hängt doch wie immer ab von der zu verwaltenden Datenmenge, Transaktionsvolumen, Spitzenlasten, Anzahl und örtliche Verteilung der User. Für ein globales Unternehmen sind neuere verteilte Datenbanktechniken besonders interessant. Bei einem einzelnen Standort wäre das aber mit Kanonen auf Spatzen geschossen, noSQL geht aber auf jeden Fall auch mit kleinen Datenmengen.

    Tschüß, Olaf.

    Montag, 14. Januar 2013 12:59