Probleme mit SQL-Datentypen

[Stevie]

Hansa, er denken, dann posten!
Hast du schonmal überlegt, wie viele verschiedene Arten von Datenbank-Anwendungen es gibt??

Daten in Tabellen speichern kann doch wohl jede Datenbank, oder?

Also, nur einmal angenommen, ich will ne Projekt-Management-Software schreiben.
Sowas kann doch wohl ohne Datenbank-spezifische Dinge auskommen, oder?
Wenn ich jetzt das Teil an meine Kunden verkaufen möchte,
dann kann ich doch schlecht sagen: Oh, sie haben Oracle im Einsatz?
Tja, meine Software ist aber für MSSQL entwickelt. Da müssen sie leider umsteigen bzw. sich MSSQL anschaffen.
Ergebnis: Du kannst dein ach so tollen Programm nehmen und nach Hause gehen!

Andere Möglichkeit: Du hast dein Programm so konzipiert, dass es auf mehreren Datenbanken läuft und du bist fein raus.

Ich hoffe, ihr versteht, was ich meine.

Es gibt Bereiche, da muss man sich auf eine Datenbank festlegen und sich bereits im Vorraus darüber Gedanken machen.
Aber es gibt auch Bereiche, wo es durchaus sinnvoll - wenn nicht gar falsch wäre - sich auf eine Datenbank festzulegen!

Aber zurück zum Thema:

Da du ja Zeos verwendest, kannst du ja anhand des Protokolls ermitteln, welche Datenbank zu ansprichst.
Und anhand dessen benutzt du das für diese Datenbank korrekte Script zum erstellen deiner Tabelle(n).

MfG
Stevie

[Neelix]

Zitat von Hansa:

Den Enduser interessiert doch die Datenbank nicht die Bohne.

Hier irrt der große Meister. Ich kenne genügend Firmen, die haben eine eigene IT-Abteilung und ein angeschlossenes Rechenzentrum. Da gibt es sehr wohl Vorgaben, welche DB eingesetzt wird. Das hängt zum teil davon ab, welches ERP-System genutzt wird. Und da findest Du alles begonnen bei SAP-DB, MS SLQ-Serevr (Navision!) bis hin zu Oracle. Das heißt also, wenn Du dort ein Standard-Programm für irgendeinen anderen Einstazbereich an den Mann bringen willst, dann mußt Du diese DB auch unterstützen oder Du bist von vornherein aus dem Rennen!

Zur Frage, eventuell solltest Du Schnittstellen zu den einzelnen DV's schreiben, die dann deine Fachlichkeit in die einzelnen "DB-Jargons" übersetzen.

[Jasocul]

@Mods: Sorry für OT, aber ich möchte noch was los werden.

@hansa:
Du siehst das Problem von der falschen Position. Es hat nichts mit Programmierern zu tun, sondern ist eine administrative und kaufmännische Problemstellung! Da geht es auch nicht um den Applikations-Anwender.
Die meisten Unternehmen setzen kaufmännische Applikationen ein. Folge: Eine DB ist vorhanden.
Fast jeder GF und Admin wird es vermeiden eine weitere DB zu kaufen/installieren. Für mich war es sogar entscheidend, dass die zweite DB-Applikation ebenfalls unsere vorhanden DB unterstützt.

Bei einer gängigen Applikation (z.B. Fibu) wird kein Hersteller umhin kommen, für mehrere DBs zu programmieren, wenn er nicht vom Markt verschwinden will. Und wenn die DB-Struktur erstmal stimmt, ist die meiste Arbeit sowieso im Source und nicht auf der DB. Dass man damit eine DB nicht mehr effektiv nutzen kann, steht außer Frage. Da aber Source-Änderungen in jedem Fall nahezu gleich lange dauern, ist dein Argument der Verzögerung blödsinn. Ein guter SW-Hersteller benötigt die meiste Zeit sowieso zum Testen.

Bei einer Individual-Lösung hast du definitiv recht. Aber darum geht es hier offensichtlich nicht, da man in dem Fall nicht mehrere DBs unterstützen muss.

Wenn du jetzt noch weiter darüber diskutieren möchtest, dann doch bitte als eigenen Thread oder als PN.

On-Topic:
leider kenne ich obige DBs nicht gut genug. Bei Oracle kann man sich eigene Typen und Aliase definieren. Habe ich zwar bisher nicht benötigt, aber vielleicht gibt es sowas auch bei mySQL, MS-SQL und Firebird.

[Hansa]

Ich kenne die anderen jetzt auch nicht gut genug. Bei Interbase würde ich mir in diesem Zusammenhang mal die Domains angucken. Und zum Rest : mir ist schon klar, daß jemand der Oracle gekauft hat, diese DB auch nutzen will. Das sollte IMHO aber nicht zum Selbstzweck ausarten. Gibt es bessere Programme, dann glaube ich kaum, daß die DB noch eine Rolle spielt. Genausowenig, wie wenn ich Firebird zum selben Preis direkt mitliefern kann. Wie dem auch sei, ich werde nachher noch einen treffen, der in Weltfirma arbeitet (Name kann ich leider nicht nennen). Werde den mal fragen, wie das bei denen gehandhabt wird. Bevor hier aber jetzt der falsche Eindruck entsteht, ich hätte was gegen das Vorhaben insgesamt : baut jemand ein Tool, das auf eine bestehende Datenbank zugreifen muß, dann bleibt ihm wohl nichts anderes übrig. Hier im Forum bin ich allerdings jetzt eher tatsächlich von einer Einzellösung ausgegangen. Hierzu müßte aber dann der Fragesteller Auskunft erteilen.

[Bernhard Geyer]

Zitat von Hansa:

So ist es. Du mußt für so was den kleinsten gemeinsamen Nenner finden. Dies bedeutet allerdings IMHO : es wird ein schlechtes und lahmes Programm werden.

Das stimmt so nicht. Man kann auch mit dem Basisdatentypen fast alles abdecken
Und für die Geschwindigkeit kommt es mehr auf ein vernünftiges Datenmodell und geschickte Anwendung von SQL (Indexe, ...) an.

Zitat von Hansa:

Ich würde es aus weiteren Gründen nicht kaufen : eine von mir angeregte Änderung müßte für mehrere DBs geschrieben werden. Egal wie, es würde länger dauern und teurer werden als für mich nötig.

Stimmt auch nicht unbedingt. Wenn Du ein gute DB-Abstraktionsschicht verwendest/entwickelt hast dauert es nicht viel länger die Erweiterung für mehrere DB's zu implementieren als nur für eine. Und wenn man schon mal eine Abstraktionsschicht hat, ist der Aufwand um neue DBMS zu unterstützen auch nicht mehr die Welt (gegenüber einem großen Anwendungsumbau).

Zitat von Hansa:

Den Enduser interessiert doch die Datenbank nicht die Bohne.

Eben schon. Wir haben Kunden die sagen: Programm schön und gut, aber nur wenn es auf der Datenbank xyz läuft. Und wenn du die wichtigsten unterstützt (Oracle, MS-SQL, ...) so fällt man nicht heraus wenn man nur eine Datenbank unterstützt.