Probleme mit SQL-Datentypen

[hsbc]

Hallo allerseits,

Ich schreibe gerade ein Programm, mit welchem ich mehrere Tabellen mittels SQL für mySQL, MSSQL und Firebird anlegen möchte. Nach Möglichkeit möchte ich nur solche Datentype verwenden, welche auf allen drei Servern laufen.
Nun habe ich Probleme mit folgenden SQL-Datentypen:

DATE bzw. DATETIME:
DATE läuft nicht auf MSSQL
DATETIME läuft nicht auf Firebird
Gibt es hier eine Alternative, welche auf allen 3 genannten Servern läuft?

BOOL: läuft nicht auf MSSQL
Welche Datentype kann man alternativ hier verwenden, die wieder auf allen 3 genannten Servern läuft?

Für Hinweise wäre ich wieder sehr dankbar.

mfg
Herbert

[shmia]

Da gibt es nur wenige Möglichkeiten: du erfindest deine eigenen Datentypen und ersetzt diese zum Zeitpunkt
wenn die SQL Anweisung zur Anwendung kommen soll. z.B.

SQL-Code:

CREATE TABLE tabelle4711( datum $DATETIME$ NOT NULL)

Die Dollarzeichen helfen dir beim ersetzen.

Beim MS SQL kann man benutzerdefinierte Datentypen verwenden.
Wenn du einen benutzerdefinierte Datentyp einmal verwendet hast, kannst du ihn nie mehr ändern!!

[Bernhard Geyer]

Zitat:

Zitat von hsbc

BOOL: läuft nicht auf MSSQL

bit?

[shmia]

Zitat:

Zitat von Bernhard Geyer

Zitat:

Zitat von hsbc

BOOL: läuft nicht auf MSSQL

bit?

Ach ja....
der MS SQL Server kennt die Konstanten True und False nicht.
Also müssen Bedingungen mit wert=0 sowie wert<>0 formuliert werden.

[hsbc]

Gibt es eigentlich irgendwo eine Tabelle mit Gegenüberstellung der Datentypen der einzelnen Server?

Wo kann man überhaupt nachlesen, welche Datentypen welcher Server unterstützt? Ich finde da so nirgends eine befriedigende Antwort.

Ansonsten danke schon mal für die Beiträge. Habe befürchtet, dass ich da noch so einiges ändern werde müssen.

mfg
Herbert

[Bernhard Geyer]

Wenn Du für mehrer DBMS-Systeme eine Anwendung schreiben willst, so solltest Du folgendes befolgen:

- Nur Basistypen wie String/Blob/Integer verwenden
- Datumswerte in festen Format speichern (z.B. ISO-Datumsformat yyyy-mm-dd)
- Boolwerte als varchar(1) oder int definieren und entsprechen False festlegen (z.B. '0' bzw. 0)

[freak4fun]

Um zu erfahren, was es an Felder gibt, kannst du ja alle 3 Tabellen mal erstellen, um zu sehen, was möglich ist. :thumb:

Und dann eine Übersicht erstellen.

MfG
freak

[Hansa]

Zitat:

Zitat von Bernhard Geyer

Wenn Du für mehrere DBMS-Systeme eine Anwendung schreiben willst, so solltest Du folgendes befolgen:

- Nur Basistypen wie String/Blob/Integer verwenden
...

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. 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. So was will keiner. Eventuell kommst Du an einen Punkt, wo die Zieldatenbank nicht mehr mitmacht. D.h.: das Programm wird zu sich selber inkompatibel. usw. Der Ansatz sieht zwar vernünftig aus, im Endeffekt ist er es aber nicht. Den Enduser interessiert doch die Datenbank nicht die Bohne.

[Jasocul]

Zitat:

Zitat von Hansa

Den Enduser interessiert doch die Datenbank nicht die Bohne.

Es sei mal dahingestellt, ob das ganze sinnvoll ist.
Aber mich interessiert es sehr wohl welche DB dahinter steht. Wenn ich mehrere DB-Applikationen habe, will ich nicht auch noch mehrere DBs haben und administrieren.
Mir kommt jedenfalls keine MS-SQL-DB ins haus. So hat jeder seine Vorlieben. Das soll jetzt aber keine Diskussion werden, welche DB die beste ist. MS-SQL sollte nur ein Beispiel sein. Eine gute, intensiv genutzte DB braucht einen eigenen Server (Hardware). Soll ich für jede DB-Applikation einen eigenen DB-Server einrichten?
Hansa, bleib realistisch.

[Hansa]

Tja, wer weiß. Mir wäre es zumindest wichtiger zu wissen, daß das Programm macht, was es soll und ich schnellen Support habe. Ausreden, daß ein Update länger dauert, weil der MySql Teil noch immer nicht funktioniert zählen eben nicht. Weil es keine Sau interessiert. Was ist MySql ? Bzw. wer weiß das bzw. hat nur den Namen schon mal gehört ? Jasocul, ich rede jetzt vom Enduser und nicht von einem Programmierer. Meine Philosophie ist es, besser etwas komplett 100 % richtig zu machen, als 10 Sachen nur zum Teil. Wenn es nun heißt, das Programm benutzt Oracle, dann ist das eben so. Ist das Programm gut, dann wird es gekauft. Mit Sicherheit allerdings eben nicht wegen Oracle oder MySql.

[Stevie]

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

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

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:

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:

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:

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:

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.