Was braucht der User?

[CalganX]

Hi,
ich bin derzeit am überlegen, wie ich meine Programme ausweiten kann. Im Moment bin ich am überlegen, ob ich ein Programm auf Datenbanken umstelle...
Nun meine Frage: Was braucht der User, um das Programm nutzen zu können???

Chris

[xbu58]

Hallo Chris

Das ist stark davon abhängig, welche Datenbank Du einsetzen möchtst. Meiner Meinung gibt es nur eine wirkliche saubere Lösung und das ist der Einsatz eines SQL-Server. Das kann z.B. MS SQL-Server (recht teuer, ab ca. 1000 Euro für 5 User), Sybase SQL-Anywhere (Server + 1 User ca. 500 und pro weiterer User ca. 150 Euro) oder InterBase, die mit Delphi Enterprise mitgeliefert wird. Sie ist aber auch Lizenzpflichtig, kenne aber die Preise nicht. Wie Du siehst, ist es also wichtig, zuerst zu wiessen, wie Du das Produkt im Markt platzeren willst.

Eine andere Möglichkeit ist den MS-Jet 4 OLE DB Provider ein zusetzt, den Du über die ADO-Komponenten benutzen kannst. Dieser Provider soll recht gut sein. Ich selber habe diese Provider noch nie eingesetzt, da ich nur mit SQL-Server und SQL-Anywhere arbeite oder XML verwende, wenn ich Daten ablegen muss.

Gruss
Xaver

[Hansa]

Hi,

Zitat:

Zitat von xbu58

oder InterBase, die mit Delphi Enterprise mitgeliefert wird. Sie ist aber auch Lizenzpflichtig, kenne aber die Preise nicht.

Schau am besten mal in FAQ oder so : "Welche Datenbank ?". Zu Interbase ist noch zu sagen, daß es eine Open Source Version gibt, die NICHTS kostet. Borland will mittlerweile Geld dafür. Firebird heißt zwar anders, ist aber nichts anderes als Interbase als Open Source. Weder der Server noch die Clients kosten Geld. Ich teste das im Moment und habe noch keinen Bug festgestellt. Das läuft völlig stabil.

Allerdings bist Du nicht der erste den ich davor warne, zu denken : "Ach, dann setze ich einfach halt eine SQL-Datenbank ein!" :!: Ich selbst habe mich bereits vor über 10 Jahren mit dem Thema intensiv beschäftigt. Es aber nie in der Praxis richtig durchgezogen, da bin ich gerade dabei. Kenne also schon die Grundlagen der Theorie, aber da gibts manche Hürde zu überwinden. :!:

Gruß
Hansa

[xbu58]

Hallo Hansa

Was die Hürden betrifft kann ich Dich nur unterstützen. Ich arbeite nun schon 15 Jahre mit SQL-Datenbanken von Uify auf Unix über Orakle und Sybase SQL-Server ab System 4.5 bis 10 und SQL-Server von MS und nun auch noch mit SQL-Anywhere. Habe auch schon MySQL ausgetestet, und als untauglich verworfen. Es braucht wirklich einige Zeit, bis man eine Datenbank wirklich einsetzen kann. Das Problem ist häufig die fehlenden oder ungenügenden Admin-Tools, welche mit der DBS mitgeliefert wird (es gibt ja immer noch so Spezialisten, die nur ein ISQL auf Shellbasis mitliefern). Deshalb bin ich nun am entwickeln eines Admin-Tools für SQL-Server und SQLAnywhere. Da schlägst Du dich mit Problemen herum, die der normale DB-Entwickler nicht hat (z.B. wie hole ich die User und der Role-Zugehörigkeit aus der DB oder wo sind die Stored procedures gespeichert). Ich habe im Sinn, auch weiter DB's in meinem Admin-Tool zu unterstützen. Würde mich deshalb interessieren, wo man die Firebird herunter laden kann. Wenn diese DB geeignet ist, werde ich sie ev. einbauen.

Gruss
Xaver

[Hansa]

Hmmm,

guck mal nach. www.mers.com.
Gruß
Hansa

[harrybo]

oder unter www.ibphoenix.com.

@Hansa: mit welchen DataAccess Componenten arbeitest Du beim Einsatz von Firebird? InterXpress ist zwar mit 69$ bezahlbar, aber eben auch nicht kostenlos.

Gruß, harrybo

[MrSpock]

Hallo Chris,

um die Frage sinnvoll beantworten zu können, musst du noch ein paar Infos rausrücken :mrgreen: .

Läuft das Programm als stand alone oder im Netz? Wieviel User greifen gleichzeitig auf die Daten zu (falls es im Netz läuft)? Wieviele Datensätze und Tabellen willst du verwalten?

Denn es könnte auch sein, dass Paradox völlig ausreicht.

[xbu58]

Hallo MrSpock

Ich denke, dass die Entscheidungsgrundlage, ob mit Paradox oder einem DBS gearbeitet wird, ist nicht ob stand alone oder Netz, sondern ob Single-Task oder Multi-Task. Man muss sich dabei im klaren sein, dass schon der Einsatz eines Threats das gleiche Problem auslösen kann, wie zwei User. Diese leidige Erfahrung habe ich vor einiger Zeit machen müssen, als ich aus Kostengründen auf Paradox gesetzt habe. Ich würde meinen, dass MySQL hier doch noch eine etwas besser Lösung ist, auch wenn vom Relation-Ship-Konzept her dieser DBS nicht ausreicht. Aber mit MySQL wird midestens ein Server gestartet, der für das Locking zuständig ist! Ausserdem kann ODBC zugegriffen werden, was auch ein Vorteil gegenüber Paradox ist.

Du hast natürlich recht, dass mit den Angaben von Chris noch nicht gesagt werden kann, was Sinnvoll ist.

Gruss
Xaver

[MrSpock]

Hallo xbu58,

es ist ja nicht so, dass Paradox ungeeignet ist für Netz- oder Multitasking bzw. Multithreatanwendungen. Ich habe sehr gute Erfahrungen seid vielen Jahren mit Paradox im Netz. Bei Zugriffen von 5-10 Usern und vielleicht bis zu 20 Tabellen mit bis zu einigen 1000 Datensätzen sehe ich Paradox als nicht überfordert an. Wie gesagt, ich denke dass SQL - Datenbanken eine gute Entscheidung sein können, aber man sollte zunächst wissen, was denn eigentlich gemacht werden soll. Insbesondere, wenn das Programm von Chris bisher ganz ohne DB auskam, erwarte ich nicht unbedingt sehr große Anforderungen...

[Hansa]

Hi,

Zitat:

Zitat von harrybo

@Hansa: mit welchen DataAccess Componenten arbeitest Du beim Einsatz von Firebird?

Im Moment mit FIBplus, geht eigentlich recht gut. Kosten ca. 160 $ mit Source, Support auch gut, selbst bei Evaluating-Version Antwort vom Entwickler selbst. www.devrace.de

Das oben angesprochene Admin - Tool betreffend :

Bitte mal dies hier ausprobieren : www.ibexpert.de

Zitat:

wenn das Programm von Chris bisher ganz ohne DB auskam, erwarte ich nicht unbedingt sehr große Anforderungen...

Dem ist nichts mehr hinzuzufügen.

Gruß
Hansa

[Hansa]

Hi,


OFF TOPIC:

Dem ist in der Weihnachtszeit doch noch etwas hinzuzufügen :mrgreen: :mrgreen: :mrgreen: Das ist aus der IBexpert NewsGroup! Wirklich Köstlich!

[CalganX]

@ MrSpock: Vorerst stand alone auf einem Rechner. Später wäre es denkbar, dass ganze auf das Netzwerk auszuweiten...

Chris

[xbu58]

Hallo MrSpock

Warscheinlich hast Du recht. Ich schlage mich eben mit Datenbanken herum, welche über 200 Tabellen und Grössen 100 MB nun mehr (grösste bei einem Kunden DB ist über 1 GB), wobei in einige Tabelle mehr als 1 Mio Datensätze enthalten sind. Deshalb denke ich da ev. in etwas zu grossen Dimensionen.

Gruss
Xaver

[Hansa]

Hi,

Zitat:

Zitat von xbu58

Ich schlage mich eben mit Datenbanken herum, welche über 200 Tabellen und Grössen 100 MB nun mehr.

:shock: 200 Tables ? Also ich hab hier fast alles berücksichtigt, was es so gibt, ob Artikel, diverse Gruppen, Vertreter, Fahrer, Azubis, Kunden, Lieferanten, Lagerbestände usw. 14 Tables sind fertig. Maximal komme ich auf ca. 38. Aber 200 ?? 100 kann ich mir noch vorstellen, aber 200 :?: Aus meiner Erfahrung sage ich jetzt einmal : das gibt Redundanzen ohne Ende und die entsprechenden Fehler.

Gruß
Hansa

[xbu58]

Na ja, ein ERP-System mit Realtime-Datenerfassung direkt ab Maschine (in einem Fall 480 Webmaschinen). Da ergeben sich schon einige Tabellen mehr.

[Hansa]

Hi,

Zitat:

Zitat von xbu58

ERP-System

Was ist das ? Naja, wenn Du nicht direkt für die Struktur der Tables ALLEINE verantwortlich bist. :mrgreen: Aber 200 ! Da staune ich immer noch. :shock: Wie es auch sei, dann bist Du eine Art Guru. :mrgreen: Wenn Du mir dann auch mal hilfst...... :chat:

Gruß
Hansa

[xbu58]

So schlimm wie es aussieht ist es auch wieder nicht. Ja, ich bin für diese Strukturen unter anderem verantwortlich. Aber wenn Du die richtigen Design-Tools für die Datenstrukturen hast und ein entsprechende mächtiges DB-Admin-Werkzeug besitzt, ist es eigentlich kein grosse Problem eine solche Datenbank zu verwalten.

Was ist ein ERP-System? Nun das ist eine Abkürzung für Enterprise Resource Planning. Dabei handelt es sich um ein System, mit dem man alle Resource in einer Firma managet. Du kennst ev. den Begriff PPS. Ein ERP ist eigentlich ein PPS (Produktionsplanung und Steuerung) mit der Integration der Einkaufs und Verkaufssysstem eben einfach alles, was man in einer Firma braucht.
Du hast natürlich recht, dass da auch einige Redundanzen vorhanden sind. Das hängt jedoch damit zusammen, dass in einem solchen System eine enorme Datenmenge anfählt. Nur ein ein Beispiel: bei dem erwähnten Kunden mit den 480 Maschinen müssen pro Minute ca. 500-1000 Datensätze gespeichert werden und das 24h am Tag und das 360 Tage lang, und das auf einem Rechner mit 2 Pentium 3 800MHz! Da kannst Du glatt weg vergessen, dass diese Datenmengen noch mit irgend welchen komplezen Algorytmen versehen kannst. Da musst Du nur dafür sorgen, dass diese Daten gespeichert sind. Danach musst Du mit anderen Processen dafür sorgen, dass diese Datenmengen so verteilt werden, dass die Antwortzeiten für den Anwender im Sekunden-Beriche liegt. Da kannst Du nicht 100'000 Rows durchsuchen!
Du siehst also, dass ich schon ein wenig von Datenbanken verstehe, auch wenn ich mich nicht als Guru bezeichnen würde. Aber 15 Jahre Erfahrung mit Datenbanken na ja das ist schon etwas.

Gruss
Xaver

[MrSpock]

Hallo Chris,

ich empfehle für diesen Fall, mit Paradox anzufangen. Ich gehe davon aus, dass auch deine nächste Version im Netz damit gut läuft. Du kannst -wenn es wirklich nötig ist- die TQuery Komponente mehr nutzen als die TTable Komponente, um einen späteren Umstieg auf einen SQL Server zu erleichtern, aber ich denke, dass du mit Paradox und TTable gut zurecht kommst.

[harrybo]

Zitat:

Zitat von Hansa

Hi,
...
Im Moment mit FIBplus, geht eigentlich recht gut. Kosten ca. 160 $ mit Source, Support auch gut, selbst bei Evaluating-Version Antwort vom Entwickler selbst. www.devrace.de
...

danke für die Info, Hansa.

gruß, harrybo