Hi.
Hm, ich kenne es halt bisher nur als eine „Einheit“ wo die
meiste Programmierung in der Datenbank stattfand und einiges
*duck* halt in den Maske realisiert werden musste.
Da braucht man sich ja nicht vor meiner Reaktion ducken 
Ich habe es selber lange so gemacht. Allerdings bin ich draufgekommen, dass ich mir einiges an Arbeit spare, wenn ich ein Interface unabhängig von der Datenbank mache… Das war am Anfang mit Delphi. Jetzt sind es halt JSP - Seiten.
Bei den Preisen von z.B. Oracle kann man das ja auch erwarten
Ich meinte damit nicht unbedingt die Tools von Oracle. Auch ist Oracle bestimmt nicht die Lösung für jeden. Es muß schlichtweg nicht Oracle sein, um es nochmal klar auszusprechen. Es gibt Datenbanken, die gratis und sehr schnell sind. MySQL ist da ein sehr gutes Beispiel. Man kann das DBMS zwar nicht als vollständige relationale Datenbank bezeichnen… aber trotzdem ist ein wirklich großer Teil aller dynamischen Webseiten im WWW auf mySQL aufgebaut. Meine Homepage läuft mit InstantDB, einer gratis-DB auf Java-Basis.
Die Tools, auf die ich hindeuten wollte, waren z.B. ErwinSQL und Database - Explorer von Borland (bzw. Inprise). Mit diesen beiden Tools baue ich fast jede Datenbank auf.
Hm, da hast du mich nun verloren…
Access benutzt doch eine völlig andere Sprache als z.B. mysql
oder Oracle.
Alle Datenbanken sprechen SQL. Mit SQL kannst du alles auf allen namenhaften Datenbanken machen.
Du solltest mal diese Anschauung verinnerlichen: Datenbanken sind alles Blackboxes, in die man jede Menge Daten hineinstopft und die man dann wieder herausholen kann. Wie schnell das jede einzelne macht, kommt auf die Skills der Programmierer bzw. auf den Preisbereich an, für die die Datenbank programmiert worden ist.
Zusätzlich haben viele Datenbankpakete noch proprietäre Oberflächen dabei, mit denen man mal schnell eine Maske machen kann.
Ich installiere mir eine Datenbank und „spreche“ ab da nur noch in SQL mit ihr. Bzw. die angesprochenen Tools sprechen in SQL mit ihr. Die einzigen Daten, die mich ab der Installation von der DB noch interessieren, sind:
- Wie heißt der ODBC-bzw. JDBC-Treiber?
- Wieviel SQL versteht die DB?
- Wie schnell kommen die Datensätze (I/O) ?
- Wieviel Speicher braucht das Teil auf meinem Rechner?
und das wars.
solche sachen wie „wenn im feld x etwas eigetragen wird, dann
überprüfe ob es eine zahl ist, falls ja, dann mache folge
Berechnung damit und lege sie in Feld y in Tabelle z ab“
Diese Logik ist eindeutig ein Fall für die Client-Software. Ich kann nur davor warnen, diese Logik mit Hilfe von Triggern in der Datenbank abzulegen.
Für mich ist die Datenbank einfach nur der Platz, wo die Daten in einer schönen logischen Ordnung und in Abhängigkeiten liegen.
Die Algorithmen, die auf Daten reagieren bzw. diese berechnen sind eindeutig im Client.
stell ich mir sehr schwierig zu portieren vor .
Wenn du nur die Daten in einem relationalen Datenbankschema ablegst, kannst du diese auch locker auf einer andere DBMS emigrieren.
Sobald die Tabelle andere Felder benutzt als memo oder integer
(halt so ekliges wie flowfields in navision financials) hat
man in bezug auf Portabilitaet doch verloren, oder seh ich da
was falsch? (Ich lass mich ja gerne belehren, aber ich mein
sowas wäre schwierig bis unmöglich und glaub mir, ich hab
schon zig Kundendatenbanken via CSV in das Programm meiner
damaligen Firma importieren müssen und da war die Grundaussage
‚Stammdaten - ja alles andere - Nie !‘
Den kleinsten gemeinsamen Nenner kannst du in jeder DB benutzen:
Alle numerischen Typen: INTEGER LONG u.s.w.
Fließkomma-Attribute: FLOAT DOUBLE u.s.w.
Alle String Typen: STRING VARCHAR MEMO u.s.w.
und meist auch DATE für Datumsangaben
und miit diesen Werten komme ich bei jeder Anwendung aus. Ich glaube nicht, dass es ein Problem gibt, dass sich nicht mit diesen Datentypen darstellen läßt.
Jupp, deswegen is access auch nur „pro Forma“ aufgeführt.
Die wahrscheinlichste Lösung wird wahrscheinlich Visual Foxpro
oder oracle sein.
Wie gesagt. Es muß nicht immer Oracle sein (besonders nicht am Anfang)
mag sein, aber ich hab halt bisher nur „propietären“
datenbanken gearbeitet die zwangweise den client aus eigenem
Hause brauchten (wo man mit den richtigen Rechten halt auch
vom client aus in die Tabellenebene absteigen konnte)
ASP greift über ODBC auf die Datenbanken zu… Es gibt fast für jede am Markt befindliche Datenbank einen ODBC-Treiber
JSP greift über JDBC auf die Datenbanken zu… the same.
*nick* an den oder Coldfusion dachte ich auch falls nicht
visual foxpro das Rennen macht.
As you like. Du kannst ja auch Handcoden
(Ich hätt j aauch kein Problem ein Programm von D*t* B*cker
oder so anzubieten, wenns läuft nur muss man halt wissen
welche Datenbank was kann.
Wenn du ein oder mehrere Programme findest, die das können, was die Firma braucht… sehr gut. Du bist aus dem Schneider.
mfG,
J.P.Jarolim
