Grundsatzfrage zu Datenbankprojekt

[stahli]

Hallo zusammen,

über die letzten Jahre habe ich ein BDE-Projekt (Paradox/DBase und Tables/Querys) zusammengestückelt, das inzwischen einen ganz guten Umfang erreicht hat. Das Projekt läuft im Netzwerk mit bis zu 10 Usern rel. zuverlässig (Dank der DP nun auch mit 64bit-PC´s).

Es sind etwa 20 Tabellen mit insg. 1Mio Datensätze verwendet. Die Haupttabelle hat etwa 40T Datensätze, der Rest sind dann diverse Detailtabellen. Monatlich werden zwei Importe durchgeführt, diverse Daten abgeglichen und Reports/Fehlerlisten erzeugt.
Weiterhin verwalten wir damit unsere Vorgänge (bei wem ist was in Bearbeitung) und Wiedervorlagetermine.

Nun steht mal eine "Generalüberholung" an, besser gesagt ein Neuaufbau.

Unser IT-Bereich entwickelt Browseranwendungen (GIS usw) - ich weiß aber nicht, mit welcher Entwicklungsumgebung. Formularanwendungen können/wollen sie nicht.

Ich halte nicht viel von Browseranwendung - jedenfalls nicht als Hauptarbeitsmittel, das man 8 Stunden am Tag durchgehend benutzt.

Daher mal ein paar Grundsatzfragen:

1) Würdet Ihr Euch Browseranwendungen "aufdrücken" lassen?
Meine VCL-Anwendung ist speziell auf unsere Bedürfnisse zugeschnitten, reagiert auf jeden Tastendruck und selektiert passende Datensätze (Table.GotoNearst) und ist mit den ganzen Formularen sehr effektiv verwendbar.
IT hat schon eingeräumt, dass sie das so mit Ihren Mitteln nicht umsetzen können.

Die weiteren Überlegungen mal für den Fall, dass die VCL (Win32/64) zum tragen kommen sollte:

2) DataBinding
Darauf würde ich keinesfalls verzichten wollen! Mal abgesehen davon, ob letztlich DB-Komponenten, Live Binding oder DSharp zum Einsatz käme.
(Die odControls nenne ich hier freiwillig nicht ;-))

3) MultiTier?
Wenn max. 10-15 User das Projekt nutzen und alle ohnehin in einem Netzwerk verbunden sind, sollte man dann der Einfachheit halber eine klassische DB-Anwendung erstellen oder doch MultiTier (z.B. mit DataSnap).
Hier mal unter dem Aspekt, dass keine Anbindung von Außen/Internet notwendig werden wird.
Die Frage ist, was unter dem Strich ein besseres Arbeiten mit weniger Schwierigkeiten ermöglicht. Ein MultiTier-Projekt verursacht ja immer etwas Mehraufwand (inzwischen natürlich nicht mehr so viel wie früher). Wiegen die Vorteile den Mehraufwand auf, wenn die Clients die DB auch problemlos direkt erreichen können?

4) ORM?
Auch in der Beziehung schwanke ich immer wieder. Zwar habe ich mir schon einiges dazu angesehen (insb. auch mORMot - Dank an Sir Rufo!), aber ich kann den Aufwand/Nutzen nicht recht nachvollziehen, insbes. auch in Bezug auf die vorgenannten offenen Fragen.
Die Businesslogik wird nicht übermäßig kompliziert werden. Klar würde ich gern komplett mit Objekten arbeiten, aber ohne DB ist ein solches Projekt natürlich nicht machbar. Wenn man dann wieder einen Aufwand betreiben musss, um die Daten in Objekte zu laden und sie dann wieder in die DB zu schreiben, sollte man dann nicht doch eher prozedural arbeiten und "klassisch" SQL-Statements nutzen?


Ich komme bei meinen Überlegungen immer wieder zu anderen Schlüssen und verwerfe sie dann wieder. :freak:
In welchem Rahmen würdet Ihr solch ein neues Projekt anlegen?

[Bernhard Geyer]

Zitat:

Zitat von stahli (Beitrag 1141365)

1) Würdet Ihr Euch Browseranwendungen "aufdrücken" lassen?
Meine VCL-Anwendung ist speziell auf unsere Bedürfnisse zugeschnitten, reagiert auf jeden Tastendruck und selektiert passende Datensätze (Table.GotoNearst) und ist mit den ganzen Formularen sehr effektiv verwendbar.

Gut Implementierte Webanwendungen stehen einer nativen Anwendung in fast nix mehr nach. Wenn du voll auf HTML5 setzen kannst wird man fast keine Nachteile in Kauf nehmen müssen. Mit JIRA haben wir sogar eine solche Anwendung die um welten besser is als manch andere native Anwendung die wir hier haben (Anwendungen auf Access-Basis - Kann man sich vorstellen wie schlecht sowas oft programmiert ist).

[Iwo Asnet]

Schieb das doch erst einmal von BDE zu ADO und auf einen MSSQL-Server (Einfach, weil der sich am Besten mit ADO versteht). Oder Firebird mit Zeos oder irgendwas in der Art.

Bei 10-15 Leuten kannst Du eine 2-Tier Anwendung machen, Die paar Connections schaft so eine DB locker.

[MrSpock]

Ich hatte auch eine ganze Reihe von Anwendungen mit Paradox Tabellen unter der BDE laufen. Eine läuft auch noch immer erfolgreich. Alle anderen habe ich mittlerweile auf Firebird migriert. Bei 10-15 usern genügt eine klassische DB Anwendung. Mit Browseranwendungen im Datenbankbereich habe ich keine Erfahrungen. Wahrscheinlich deswegen würde ich eher eine normale Delphi Anwendung mit guten DB Komponenten schreiben. (Ich benutze FibPlus.)

[jobo]

Deine Beschreibung klingt so, als ginge es um eine sehr spezifische, firmeninterne Anwendung. Bei der vielleicht niemals die Frage entsteht, ob sie auch außerhalb der Firma, via Intranet/VPN oder sogar frei angewendet wird. Das wäre m.E. ein sehr guter Grund für eine Browserlösung. Sonst würde ich nicht auf den Komfort (bei Implementierung und Verwendung) einer Formularanwendung verzichten wohlen (Tastaturbedieung, usw. usw., andererseits gehört schon was Liebe zum Detail dazu, eine solche Anwendung auch wirklich zu erstellen ). Deployment und Pflegeaufwand wären in der Größenordnung sicher auch eher zugunsten einer 2 Schichtanwendung einzuordnen.
Also reicht eine 2 Schichtanwendung, selbst wenn es mehr als 15 (gleichzeitige) Benutzer werden.
Muss es eine kommerzielle DB sein? Firebird wurde ja schon vorgeschlagen. Wenn es etwas(!) kosten darf, würde ich Oracle auf jeden Fall MSSQL vorziehen. Eine "SE one" tuts allemal und ist bezahlbar. Meine (schlechten) MSSQL Erfahrungen sind allerdings schon 10 Jahre her. Ich weiß nicht, was sich da mittlerweile getan hat. Wenn konkurrierende Zugriffe, Sperrverhalten usw. kein Thema sind, ist aber auch das wohl egal.

[mkinzler]

Jedem Admin rollen sich jetzt die Zehennägel hoch, wenn sie an die Installationund Wartung von Oracle denken.

[p80286]

Was MSSQL und ORACLE angeht, kann ich JoBo nur zustimmen.
Mir ist allerdings im letzten jahr ein Browserfrontend "aufgedrückt" worden. Wenn es läuft, ist nichts dagegen zu sagen, wenn es allerdings irgendwo hakt, ist immer der andere Server schuld, oder das Betriebssystem oder ....
Übrigens haben wir auch einen Feuervogel im Einsatz, der vor allem durch Unauffälligkeit und Stabilität auffällt. (ca. 40 Benutzer)

Gruß
K-H

[stahli]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1141366)

Gut Implementierte Webanwendungen stehen einer nativen Anwendung in fast nix mehr nach. Wenn du voll auf HTML5 setzen kannst wird man fast keine Nachteile in Kauf nehmen müssen. Mit JIRA haben wir sogar eine solche Anwendung die um welten besser is als manch andere native Anwendung die wir hier haben (Anwendungen auf Access-Basis - Kann man sich vorstellen wie schlecht sowas oft programmiert ist).

Ich habe mir mal ein Video angesehen. Das ist natürlich sehr umfangreich. Aber irgendwie fühle ich mich mit (guten) Formularen doch deutlich wohler.
Man stelle sich vor, Emba würde die IDE in einem Browser präsentieren. :shock: Dazu kommt es hoffentlich bis zu meiner Rente nie!

Zitat:

Zitat von Iwo Asnet (Beitrag 1141386)

Schieb das doch erst einmal von BDE zu ADO und auf einen MSSQL-Server (Einfach, weil der sich am Besten mit ADO versteht). Oder Firebird mit Zeos oder irgendwas in der Art.
Bei 10-15 Leuten kannst Du eine 2-Tier Anwendung machen, Die paar Connections schaft so eine DB locker.

Also das muss schon mal alles neu werden. wenn ich den Code sehe, den da jemand :duck: seit 15 Jahren hineingeschrieben hat ... das ist schon fürchterlich. ;-)
Außerdem sind einige Teile inzwischen wieder überflüssig etc.

Zitat:

Zitat von jobo (Beitrag 1141434)

Deine Beschreibung klingt so, als ginge es um eine sehr spezifische, firmeninterne Anwendung. Bei der vielleicht niemals die Frage entsteht, ob sie auch außerhalb der Firma, via Intranet/VPN oder sogar frei angewendet wird. Das wäre m.E. ein sehr guter Grund für eine Browserlösung. Sonst würde ich nicht auf den Komfort (bei Implementierung und Verwendung) einer Formularanwendung verzichten wohlen (Tastaturbedieung, usw. usw., andererseits gehört schon was Liebe zum Detail dazu, eine solche Anwendung auch wirklich zu erstellen ). Deployment und Pflegeaufwand wären in der Größenordnung sicher auch eher zugunsten einer 2 Schichtanwendung einzuordnen.
Also reicht eine 2 Schichtanwendung, selbst wenn es mehr als 15 (gleichzeitige) Benutzer werden.
Muss es eine kommerzielle DB sein? Firebird wurde ja schon vorgeschlagen. Wenn es etwas(!) kosten darf, würde ich Oracle auf jeden Fall MSSQL vorziehen. Eine "SE one" tuts allemal und ist bezahlbar. Meine (schlechten) MSSQL Erfahrungen sind allerdings schon 10 Jahre her. Ich weiß nicht, was sich da mittlerweile getan hat. Wenn konkurrierende Zugriffe, Sperrverhalten usw. kein Thema sind, ist aber auch das wohl egal.

Ja, es ist eine Amtsinterne Anwendung zur Verwaltung von Daten für Müllgebühren und entsprechende Vorgänge (Schriftverkehr, Anträge usw.).
Ich hatte vor Jahren schon einmal bei unserer IT angefragt, ob ich einen DB-Server nutzen könnte (die sind für diese Entscheidungen zuständig) und da hieß es: Nein, ich wäre ja nicht zertifiziert. Also blieb es bei der BDE, wobei man nun aber mal Alternativen andenken sollte.
Dass eine klassische DB-Anwendung reicht, ist eigentlich schon klar (Ein DB-Server wäre ja ansich schon mal eine Verbesserung zur BDE).
Meine Frage wäre vor allem, ob sich eine Multi-Tier-Variante in der Form lohnen würde, dass man (quasi automatisch) übersichtlicher arbeitet durch die Trennung in die einzelnen Schichten.
Ich würde natürlich heutzutage auch die Businesslogik nicht mehr direkt in die Ereignisbehandlungen schreiben, aber wie man es genau am geschicktesten löst, das ist noch die Frage.

Zitat:

Zitat von mkinzler (Beitrag 1141435)

Jedem Admin rollen sich jetzt die Zehennägel hoch, wenn sie an die Installationund Wartung von Oracle denken.

Die Administration der DB liegt auf jeden Fall bei IT. Welche DB die im Einzelnen genau haben, weiß ich momentan gar nicht. Es sind aber einige verschiedene. Momentan geht es mir eher noch um grundsätzliche Überlegungen. Im Moment steht noch nicht einmal fest, wer überhaupt entscheidet, wann überhaupt wer irgendwelche Festlegungen trifft. ;-)

Zitat:

Zitat von p80286 (Beitrag 1141449)

Mir ist allerdings im letzten jahr ein Browserfrontend "aufgedrückt" worden. Wenn es läuft, ist nichts dagegen zu sagen, wenn es allerdings irgendwo hakt, ist immer der andere Server schuld, oder das Betriebssystem oder ....

Ja, wir haben auch einige im Einsatz, die aber nur temporär für bestimmte Auskünfte genutzt werden. Das geht von Katastrophe bis ganz gut. Aber den ganzen Tag will ich mit keinem arbeiten.


Mal schauen, wie es weiter geht. Als erstes werden wir uns mal entscheiden müssen, ob wir eine Browser-App überhaupt akzeptieren würden. Dann sind wohl noch die Kosten zu diskutieren. Oha! Es wird wohl bei der BDE bleiben. :stupid:

[Bernhard Geyer]

Zitat:

Zitat von Iwo Asnet (Beitrag 1141386)

Schieb das doch erst einmal von BDE zu ADO

Um dann bei der nächsten abgekündigten Technik zu landen. ADO ist doch (wie ich auch erst vor kurzen bemerkt habe) abgekündigt.
Also zurück zum "guten alten" ODBC (oder zur nativen Bibliothek der entsprechenden DB).

[Bernhard Geyer]

Zitat:

Zitat von mkinzler (Beitrag 1141435)

Jedem Admin rollen sich jetzt die Zehennägel hoch, wenn sie an die Installationund Wartung von Oracle denken.

und nicht nur denen.
Mussten vor kurzen erst unsere App auf einem Citrix-Server zum laufen bringen bei dem der (DB?)-Admin keinen plan hatte was jetzt für ein NET-Client installiert ist und welche TNS-Datei nur wirklich gezogen wird :twisted:

[jobo]

Zitat:

Zitat von mkinzler (Beitrag 1141435)

Jedem Admin rollen sich jetzt die Zehennägel hoch, wenn sie an die Installationund Wartung von Oracle denken.

Nun, das halte ich für stark übertrieben, auch wenn ich glaube, dass es solche Admins gibt. Ich arbeite (Entwicklung) und administriere Oracle DB seit Jahren, einige von denen laufen auch seit Jahren ununterbrochen- sowohl in der Entwicklung als auch bei Kunden. Ich wills auch nicht unnötig breittreten, es gehört nicht zur Frage des TE, ich verdien nichts dran und Oracle stirbt ohne diese 15 User Lizenz auch nicht.


Multithier/

Zitat:

Zitat von stahli (Beitrag 1141454)

da hieß es: Nein, ich wäre ja nicht zertifiziert.

Ich halte das Argument Zertifizierung zwar für etwas falsch angesetzt, münzt man es allerdings auf Multithier, bist Du dann bei 2 (fehlenden) Zertifizierungen.
Das zeigt m.E. ziemlich deutlich, dass man es mit einer steigenden Komplexität in Umsetzung und Konfiguration zu tun hat und die ist vermutlich nicht mal linear.
Das ist bestimmt nicht dramatisch, ist ja sozusagen normal, die Frage ist nur, ob der Bedarf von 15 hausinternen Anwendern diesen Aufwand rechtfertigt. Den architektonischen Sexappeal der Anwendung dürften die wenigsten Nutzer zu schätzen wissen.

[bernhard_LA]

ist ADO abgekündigt ??? wo steht das denn ?? wir potieren gerade von ZEOS nach ADO :-(

[Bernhard Geyer]

Zitat:

Zitat von bernhard_LA (Beitrag 1141491)

ist ADO abgekündigt ??? wo steht das denn ?? wir potieren gerade von ZEOS nach ADO :-(

z.B. hier: http://social.msdn.microsoft.com/For...2-34044d5ef396

[bernhard_LA]

unter dem Link von oben findet dann man
..... Summa Summarum sollte man heute neue Entwicklungen den ADO.NET Sql Client
oder den SQL Server Native Client ODBC Treiber einsetzen.
Altanwendungen haben durch den längeren Horizont (7 Jahre) eine größere Gnadenfrist....



soll ich dann heute nicht mehr mit dbgo / ADO entwickeln weil dieses Thema mittelfristig nicht mehr unterstützt wird :cry:

[mkinzler]

Ja. Obwohl. man hat ja versucht mit ADO von ODBC wegzukommen und rät nun wieder zur Ur-Alt Technik ODBC. Vielleicht sieht man es in Redmond in 2 Jahren wieder anders und setzt wieder auf ADO oder was ganz neues.

[Lemmy]

Was für einen Sinn macht es eine Umstellung auf ein Produkt zu machen, das abgekündigt ist? Außer das Projekt würde in 6-7 Jahren eh eingestellt.... ansonsten würde das jetzt noch stoppen so lange nicht viel Arbeit rein geflossen ist....

@Stahli: Nutze ORM wenn Du darin schon Erfahrung hast, oder wenn Du die Zeit bekommst dich damit zu befassen (und lern bitte nicht gleich an dem Projekt, sondern setz erst mal einen Prototyp um, mit dem du ein paar wenige zentrale Funktionen die deine Anwender zwingend brauchen, testen kannst wie man das mit dem ORM umsetzt.

Firebird reicht für diese Menge an Daten und Anwendern locker aus. Somit stellst Du dir bei dir in der Abteilung einen kleinen Server incl. USV hin, dann brauchst Du die IT-Abteilung nicht einzubinden (wenn Du diese Freiheit hast).

Wenn es sehr schnell gehen soll: Schau dir mal die IBDAC an, die bieten einen BDE-WIzard an, mit dem kannst Du die Anwendung sehr schnell umstellen, allerdings musst Du diese dann noch optimieren (was Zeit kostet).

Weiterhin solltest Du dir Gedanken machen, wenn Du schon umstellst ob dein Datenbankmodell noch zur Aufgabenstellung passt. Wenn nicht - nutze die Chance einer gründlichen Überarbeitung....

Grüße

[Bernhard Geyer]

Zitat:

Zitat von mkinzler (Beitrag 1141534)

Ja. Obwohl. man hat ja versucht mit ADO von ODBC wegzukommen und rät nun wieder zur Ur-Alt Technik ODBC. Vielleicht sieht man es in Redmond in 2 Jahren wieder anders und setzt wieder auf ADO oder was ganz neues.

Mit entsprechender Kapslung dürfte der Technologiewechsel implementierungstechnisch wenige Aufwand verursachen.
Unser ADO-MSSQL-Interface ist ca. 2500 Zeilen lang. Dürfte sich also in Grenzen halten das zu wechseln.

ich würde die üblichen 3th-Party-Komponenten Verdächtigen (DevArt und Co.) fragen was sie da anbieten werden. Wenn diese den technologiewechsel im Hintegrund transparent gestalten wären die Kosten der Kompos mehr als Kostenneutral diese zu verwenden.

[bernhard_LA]

dann wird mein Code ja noch Schrottiger :shock:

Delphi-Quellcode:

{$IF DEFINED(ZEOS)}
{$DEFINE USEDATABASE}

{$ELSEIF DEFINED(BDE)}
{$DEFINE USEDATABASENOSERVER}
{$DEFINE USEDATABASE}

{$ELSEIF DEFINED(ADO)}
{$DEFINE USEDATABASESQL}
{$DEFINE USEDATABASE}

{$ELSEIF DEFINED(DBEXPRESS)}
{$DEFINE USEDATABASESQL}
{$DEFINE USEDATABASE}

{$ELSE}
{$DEFINE NODATABASE}    // Flag for Code without need for DB Interface 
{$IFEND}

mit jedem Windows Wechsel gibt es dann ein paar $ELSEIF mehr im Code und jede Menge neue Probleme und Bugs

[jobo]

OT

Zitat:

Zitat von Bernhard Geyer (Beitrag 1141467)

keinen plan hatte was jetzt für ein NET-Client installiert ist und welche TNS-Datei nur wirklich gezogen wird :twisted:

Nebenbei
Man kann das als Stärke oder Schwäche sehen, Oracle bietet allein dutzende Entwicklertools, alle können autark, nebeneinander auf einem System installiert sein. Das gleiche gilt für Datenbanken und andere Serverprodukte. Das ist natürlich nicht unbedingt übersichtlich.
Komfortable und robuste UI, gerade bei Installation, sind aber wirklich nicht Oracles Stärke. Da könnten sie sich mal ne Scheibe von MS abschneiden. M.E. merkt man bei Oracle Produkten sofort, wenn sie "ihre" Unix/Solaris Welt verlassen und das fängt ja schon auf der x86 Client Installation an.

Zu TNS
Dazu kann ich Entwickler und Admins nur empfehlen, TNSPING zu verwenden, seit Version 9 oder so, zeigt es nicht nur an, dass es irgendwo auf der DB ankommt, sondern auch welche Config Datei es dazu verwendet. Damit kostet es eine Sekunde rauszufinden, wo der Hase läuft.

Wem das zu anstrengend ist, der kann seit Version 10 Easy Connect nehmen. Hier wird der komplette Zugang im Connection String definiert, ähnlich wie bei JDBC URL, keine Konfigdateien.

[Bernhard Geyer]

Zitat:

Zitat von jobo (Beitrag 1141718)

... alle können autark, nebeneinander auf einem System installiert sein.

Eigentlich nicht. Oder schon mal geschafft den 32 und 64-Bit Client parallel und ohne weitere "Tricks" (Instant Client) parallel lauffähig installiert zu haben.

Zitat:

Zitat von jobo (Beitrag 1141718)

Dazu kann ich Entwickler und Admins nur empfehlen, TNSPING zu verwenden, seit Version 9 oder so, zeigt es nicht nur an, dass es irgendwo auf der DB ankommt, sondern auch welche Config Datei es dazu verwendet. Damit kostet es eine Sekunde rauszufinden, wo der Hase läuft.

Ist jetzt nicht mehr nötig. Haben und in der App integrierte "Systeminfo-Tool" entsprechend erweitert das es die ganzen Oracle-Relevanten Infos auch liefert. Und zwar über die verwendete Oracle-Delphi-Komponente so das wir die gleichen Infos haben welche die Komponente letztendlich verwendet.

Wem das zu anstrengend ist, der kann seit Version 10 Easy Connect nehmen. Hier wird der komplette Zugang im Connection String definiert, ähnlich wie bei JDBC URL, keine Konfigdateien.[/QUOTE]Unterstützt das auch 100% alle Feature der Konfigdatei? Ansonsten wäre es eine Möglichkeit wenn die Zugriffskompos das unterstützen.

[jobo]

OT

Zitat:

Zitat von Bernhard Geyer (Beitrag 1141719)

Zitat:

Zitat von jobo (Beitrag 1141718)

... alle können autark, nebeneinander auf einem System installiert sein.

Eigentlich nicht. Oder schon mal geschafft den 32 und 64-Bit Client parallel und ohne weitere "Tricks" (Instant Client) parallel lauffähig installiert zu haben.

Nein, in die Verlegenheit bin ich noch nicht gekommen. (Ich geh mal davon aus, dass Du ein Win7 System meinst). Ich bin bis jetzt immer damit ausgekommen, Umgebungsvariablen anzupassen.
Meine Aussage war aber ganz allgemein. Separate Konfigurationsdateien sind zunächstmal die Voraussetzung für parallele Installationen.
Ich werde mir mal den Spaß machen und Dein Beispiel ausprobieren. :)

Ez Connect

Zitat:

Zitat von Bernhard Geyer (Beitrag 1141719)

Unterstützt das auch 100% alle Feature der Konfigdatei? Ansonsten wäre es eine Möglichkeit wenn die Zugriffskompos das unterstützen.

Das kann ich mir kaum vorstellen. Wahrscheinlich muss ich mich entscheiden, ob ich es einfach haben will (Easy Connect) oder eine große Bandbreite an Konfigurationsmöglichkeiten (Net Connect/Services). Die Doku dazu hat über 200 Seiten.
Easy connect ist davon nur ein paar Seiten, Parameter gibts nur 5 oder 6, URL Host, Port. usw

[p80286]

Das ist doch wohl ein Witz??
Nachdem ich mich von ODBC gelöst habe, jetzt wieder zurück weil es ein

Zitat:

de-facto standard client connectivity API

ist?

Ein wenig bin ich ja ein ODBC-Fan, aber wenn ich soetwas lese fühle ich mich schon veräppelt.
(Wenn man mehrere DBs an eine Oberfläche koppeln muß ist ein natives API nicht so der Bringer, vor allem wenn es natürlich nichts kosten darf!)

Gruß
K-H

[Bernhard Geyer]

Zitat:

Zitat von p80286 (Beitrag 1141751)

Das ist doch wohl ein Witz??
Nachdem ich mich von ODBC gelöst habe, jetzt wieder zurück weil es ein

Zitat:

de-facto standard client connectivity API

ist?

Ein wenig bin ich ja ein ODBC-Fan, aber wenn ich soetwas lese fühle ich mich schon veräppelt.

ODBC ist Standard weil es diese Schnittstelle auch außerhalb der Windows-Welt gibt. Bei ADO/OLE DB ist das nicht der fall.

Zitat:

Zitat von p80286 (Beitrag 1141751)

(Wenn man mehrere DBs an eine Oberfläche koppeln muß ist ein natives API nicht so der Bringer, vor allem wenn es natürlich nichts kosten darf!)

Sehe ich nicht so. Haben hier 5 DB-Systeme darüber abgebildet und sind froh darüber das man bei einigen gar nix (ODBC/OLE-DB)-Technisch installieren muss.

[stahli]

Nochmal eine Frage:

In meinem BDE-Projekt habe ich einfach eine TTable und ein DBGrid verwendet. Entsprechend konnte man prinzipiell durch die gesamte Mastertabelle (40T Datensätze) scrollen - was natürlich aber niemand tut.
Aber man kann die Tabelle unterschiedlich sortieren und leicht zu benachbarten Datensätzen wechseln.

Weiterhin gibt es ein Eingabefeld für einen Suchtext. Dieser wird bei jeder Änderung (bei jedem eingegebenem Zeichen) neu interpretiert und der passendste Datensatz lokalisiert.
Dazu wird der Suchtext zerlegt und zunächst ein passender Straßenname gesucht (wobei die einzelnen Worte abgekürzt sein können) und anschließend nach einer passenden Hausnummer in der Straße. Die über die Suchfunktion gefundene Grundstücksnummer wird dann in der TTable lokalisiert.
Der Suchtext "n p9" führt dann z.B. zu "Neustädter Passage 9".

Das ist im Handling sehr angenehm und von allen gern angenommen.

Nun stellt sich für mich die Frage, wie man die Aufgabenstellung in Multi-Tier-Anwendungen löst. Hier hat man ja im Client keinen Zugang auf eine komplette Tabelle mit 40T Datensätzen, bzw. wäre es sicher nicht zweckmäßig, solche Mengen über das verwendete Protokoll zu übertragen. Oder bietet hier z.B. DataSnap intern die Möglichkeit, nur die notwendigen (weil z.B. in einem DBGrid sichtbaren) Datensätze zu übertragen? Ich denke wohl nicht.

Die gleiche Fragestellung stellt sich bei Browseranwendungen. Hier ist ja nicht denkbar, eine Tabelle mit 40T Einträgen aufzubauen, auch wenn der Inhalt der Tabelle scrollbar wäre.

Insofern hat eine klassische Datenbankanwendung (mit direkter Anbindung an einen Datenbankserver über Netzwerk) auch seine Vorzüge.

Wie seht Ihr das?

[jobo]

Sind denn die 40T Datensätze nicht mehr weiter "kleinzukriegen"?
Zunächst dachte ich ein Ort hat selten 40T Straßen, aber es geht ja offenbar um Mietparteien oder so.

Hast du Einfluss auf das Datenmodell? Wenn es normalisiert ist, steht ja nicht für jede Wohnung der Straßenname dabei, sondern lediglich ein Verweise (ID). Suchen müsstest Du dann nur noch auf den mal geschätzt 4000 Straßen einer Stadt, im 2. Schritt dann auf der Hausnummer. Steht die Hausnummer in einem separaten Feld?

Mir ist auch die Logik in der abgekürzten Suche nicht ganz klar.
"N[Leerzeichen]P9"
'Leerzeichen' steht für 'nächstes Wort'?
'N' (am Anfang) steht für (erstes) Wort beginnt mit 'N'?
'Ne' stünde für (erstes Wort) beginnt mit Ne?
Wird Großschreibung unterschieden?

Wenn Du mit einem DB Server sprichst, wäre der Like Operator gefragt.
Der funktioniert wie die Wildcards aus Dateilistings.

Wenn Du es schaffst, die Suchanfrage in einen Like kompatiblen Filter umzubauen, sehe ich kein Problem. Die meisten DB haben außerdem die Möglichkeit, schon serverseitig die Menge der zurückgegebenen Werte zu beschränken.

Um Web müsste man vielleicht mit Ajax arbeiten.
Datasnap kenne ich nicht.

[mkinzler]

Die Frage ist, ob sich der Aufwand für ein BDE-Projekt lohnt und man nicht auf eine aktuelleres DBMS wechseln sollte, welches reguläre Ausdrücke unterstützt.

[jobo]

Ich hatte stahli so verstanden, dass mit der Multi-Tier Frage auch der Wechsel von BDE auf DB-server einhergeht.

[stahli]

Ja, es geht ja gerade um einen Umstieg von der BDE zu einem ordentlichen SQL-DB-Server.

Die Frage ist nun, wie man bei einer Multi-Tier-Anwendung oder auch einer Browseranwendung mit einer großen Tabelle umgeht. Man wird wohl - um in meinem Beispiel zu bleiben - immer erst eine Straße selektieren lassen und alle weiteren Funktionen auf diese Straße begrenzen. Oder?

Wobei ich einen solchen Ansatz aber nicht wirklich schön finde. Das wäre für mich auf jeden Fall ein PRO für eine klassische Datenbankanbindung.


@jobo

Mal zum Hintergrund (wobei es darauf weniger ankommt).
Die Tabellen sind normalisiert. Die Grundstückstabelle enthält die Straßenschlüssel und die Hausnummern. Es gibt ca. 40000 Grundstücke.

Der benötigte Straßenschlüssel wird zunächst in der Straßentabelle ermittelt. Die enthält die Straßennamen und "SortStraßennamen" (mit aufgelösten Umlauten und ss statt ß).

Leerzeichen im Suchtext stehen für ein Wortende. Groß/Kleinschreibung ist nicht relevant.

"n" findet z.B. "Nachtigallensteig"
"n " auch noch
"neu" würde dagegen "Neuragoczystr" finden (siehe Bild oben)
"n p" findet "Neustädter Passage" da es die erste/einzige Straße ist, bei der das erste Wort mit "N" und das zweite mit "P" beginnt.


Mir ging es aber nicht darum, diese Funktion in SQL umzusetzen, sondern einfach darum, wie man in Multi-Tier-Probjekten oder Browseranwendungen mit großen Tabellen umgeht.
Ohne eine "Vorselektierung" oder wenigstens "Datensatzbeschränkung" wird das wohl nicht funktionieren.
Ich fände das aber ziemlich unschön und würde dann eine native Datenbankanbindung wenn möglich bevorzugen. Für das GUI-Design stelle ich mir das einfach besser vor.
Der User kann somit "die gesamte Tabelle" vor sich sehen und muss sich nicht erst bestimmte Häppchen daraus laden.

[WM_CLOSE]

Mach es doch so wie Google bei seiner Bildersuche:
Lade nur den Teil (nach) der gerade z.B. auf Grund der Scrollposition benötigt wird.

[Phoenix]

Schieb doch einfach die Sucheingabe auf den Middle-Tier, lass den Suchen und liefer nur das gefilterte Ergebnis zurück.
Und nein, das geht nicht mit DataSnap, aber DataSnap ist auch kein Middle-Tier Server sondern will nur spielen. Für Real-World Anwendungen ist das Ding nicht zu gebrauchen. Mit einem selbst gebauten Middle-Tier der anständigen Frameworks ist sowas aber kein Problem.

Edit Nachtrag: Beispiel Finanzen.net
Geb mal in der Suchmaske "Mic" ein, warte dann auf die anzeige, und verfeiner dann z.B. mit " Fonds".
Das ganze wird zum Server (Middle-Tier) geschickt, eine Volltextsuche auf die Datenbank losgelassen, bestimmte Schlagworte sorgen für eine genauere Filterung, und der Client bekommt nur noch das Ergebnis zurück. Und dafür müssen nur minimal Daten übertragen werden.

[jobo]

Wenn Du wirklich so große Datenmengen darstellen willst, kommst Du trotz DB Server nicht um eine Clientdatasettechnik rum. (wg Suchgeschwindigkeit, Transferrate und Ressourcenproblemen des Servers)
Dabei spielt natürlich die Anwenderzahl eine Rolle und auch die Hardware.

Durch filigrane Programmierung kann man eine Menge rausholen. Möglich ist vieles, ist aber die Frage wieviel Zeit und Geld man dafür in die Entwicklung steckt.

Eine WildcardSuche der gefragten Größenordnung nach 3 Anfangsbuchstaben mit sortiertem Ergebnis und eingeschränkter Ergebnismenge geht auf einem indizierten Feld unter 0,1 sek. Aber man kann nicht jedes Feld indizieren.

Ob ein gutes Framework in der Mittelschicht per se was bringt, wage ich zu bezweifeln. Die Mittelschicht ist bezogen auf den Server auch schlicht und ergreifend nur ein "Client" mit den gleichen Problemen eines klassischen Client-Server Clients.

[mjustin]

Zitat:

Zitat von jobo (Beitrag 1146954)

Eine WildcardSuche der gefragten Größenordnung nach 3 Anfangsbuchstaben mit sortiertem Ergebnis und eingeschränkter Ergebnismenge geht auf einem indizierten Feld unter 0,1 sek. Aber man kann nicht jedes Feld indizieren.

Ob ein gutes Framework in der Mittelschicht per se was bringt, wage ich zu bezweifeln. Die Mittelschicht ist bezogen auf den Server auch schlicht und ergreifend nur ein "Client" mit den gleichen Problemen eines klassischen Client-Server Clients.

Google Search ist ein gutes Beispiel. Da ist 'alles' (mehr oder weniger) indiziert, und es ist schnell. 0,1 Sekunden sind eine halbe Ewigkeit (Man bedenke mal, was eine Grafikkarte in der Zeit schafft). Google läuft auf billiger Hardware, ist aber sehr effizient programmiert.

Wenn es schnell gehen soll, wird der gesamte Datenbankinhalt ins RAM geladen (entweder auf einem einzigen oder mehreren verbundenen Rechnern - verteiltes Caching gibt es auch für Delphi), und komplett indiziert.

Die Mittelschicht (der Applikationsserver) kann viel effizienter als ein DBGrid + ClientDataSet sein, man muß sich nur eine effizientere Behandlung von Updates ausdenken. Wenn alles über den Cache geht, ist der Server immer auf dem aktuellen Stand, und braucht 'nie' auf die Datenbank zuzugreifen (sie wird in einem Backgroundprozess aktualisiert).

Warum sollte man nicht z.B. einem Client (Web oder grafisch) vom Server aus aktiv genau den Datensatz zusenden können, der neu aufgenommen wurde und einem gewählten Filter entspricht, statt den Client ein Close / Open / der gesamten Query machen zu lassen? Kompliziert ist es nicht, wenn man berücksicht, dass eine TCP/IP Verbindung immer zwei Richtungen auf einem Socket unterstützt - der Client kann also Nachrichten vom Server erhalten wenn er Lust hat, initiativ welche zu senden.

Das ist es auch, was Webseiten (Google Search) über Ajax erreichen: der Client macht keinen neuen Request auf das HTML Dokument (das dann erst wieder komplett auf dem Server zusammengebaut und an den Client geschaufelt werden müsste): es wird nur der Inhalt z.B. einer HTML Dropdownliste dynamisch um einen weiteren Eintrag ergänzt. Das geht in wenigen Mikrosekunden, auch mit Delphi. (Für eine Art "Chatsystem" auf TCP/IP Basis habe ich jetzt Raten von 30.000 Nachrichten pro Sekunde zwischen Client und Server - auf sehr einfacher Hardware - p.s. der Client ist in Delphi geschrieben, der Server ein Java Open Source Programm).

[jobo]

Im Prinzip stimmt alles was Du schreibst. Ich bin mir nur nicht so sicher, ob man das Entwicklerbudget und KnowHow von Google und Co hier einfach voraussetzen kann. Auch die Hardware dort ist für sich genommen meinetwegen billig, aber die Masse macht es dann eben. Außerdem wird bei google sicher nicht mit klassischen DB gearbeitet und sie haben mit den Alternativen Technologien auch nicht das Problem, dass sie bis ins letzte Bit ACID brauchen. Schnelle Suche ist DAS google Produkt, der Rest fällt priomäßig unter "ferner liefen".