Programmumstellung von SQLite auf PostgreSQL

Für Themen zu Datenbanken und Zugriff auf diese. Auch für Datenbankkomponenten.
Antworten
Aliobaba
Lazarusforum e. V.
Beiträge: 496
Registriert: Di 1. Mai 2012, 09:11

Programmumstellung von SQLite auf PostgreSQL

Beitrag von Aliobaba »

Hallo,

"mein" Programm "MyMemoryDB" arbeitet bestens und höchst zuverlässig und blitzschnell mit der SQLite-Datenbank unter "Zeos". Nun blitzt in mir schon mal gelegentlich der Gedanke auf, das Programm mit einer "echten" Server-Datenbank zu verbinden, um auch z.B. per Internet von verschiedensten Rechnern aus Zugriff auf seine Daten zu haben.

Ich weiß nur absolut nicht, auf was ich mich einlassen würde, wenn ich dieses Ziel verfolge. Ich denke ja schon, dass es ein wenig komplizierter ist als nur seine "TZConnection" auf das andere Protokoll (PostgreSQL würde mir sehr gefallen) umzustellen. (?)

Wie ist es zum Beispiel mit den SQL-Befehlen? Sind die überwiegend kompatibel?
Welche neue Routinen sind erforderlich, um ein zuverlässiges "Locking" der Einträge bei gleichzeitigen Zugriffen zu erreichen.

Hat dies schon jemand gemacht und kann über seine Erfahrungen berichten?

Viele Grüße und allseits ein Frohes Weihnachtsfest!
Aliobaba
"MyMemoryDB" ( https://www.heise.de/download/product/mymemorydb-89626 )

Warf
Beiträge: 1910
Registriert: Di 23. Sep 2014, 17:46
OS, Lazarus, FPC: Win10 | Linux
CPU-Target: x86_64

Re: Programmumstellung von SQLite auf PostgreSQL

Beitrag von Warf »

SQL ist standardisiert und sollte damit theoretisch kompatibel sein.
Praktisch gibt es kleinere unterschiede. Ich meine irgendwann mal gehört zu haben das MySQL (bzw. mariadb wenn du oracle nicht magst) näher an SQLite sein soll als posgresql, kann mich aber auch irren, hab noch nicht so viel mit PGSQL gemacht. Von meiner erfahrung her funktionieren die meisten SQLite queries auch in MySQL/MariaDB, von PGSQL wie gesagt, keine ahnung.
Vor allem deckt der SQL standard aber nicht alles ab, beispiel AUTOINCREMENT ist nicht teil des standards. In SQLite gibt es AUTOINCREMENT und in MySQL dafür AUTO_INCREMENT. Genauso ist sowas:

Code: Alles auswählen

CREATE TABLE ... 
...
  ID INTEGER NOT NULL PRIMARY KEY
 

Nicht standard, sondern nur eine kurzschreibweise von manchen SQL Servern für den standardkonformen code:

Code: Alles auswählen

CREATE TABLE ... 
...
  ID INTEGER NOT NULL,
...
  CONSTRAINT pk_ID PRIMARY KEY (ID)
 


Die Frage ist also auch ob du Standardkonformen SQL code geschrieben hast, oder SQLite spezifische konstrukte benutzt hast

Ich würds einfach mal ausprobieren, kann mir vorstellen das das meiste schon direkt funktioniert (noch nie mit zeos gearbeitet, aber eigentlich sollte das umstellen des unterliegenden treibers maximal eine zeile sein)

Benutzeravatar
six1
Beiträge: 788
Registriert: Do 1. Jul 2010, 19:01

Re: Programmumstellung von SQLite auf PostgreSQL

Beitrag von six1 »

MYSQL würde ich nicht ins "Internet" stellen über Portzugriff (normalerweise 3306).
Über SecurBridge von Devart kannst du aber relativ einfach einen SSH Tunnel aufbauen, über welchen dann ein Port Mapping zur Datenbank geschehen kann.
Gruß, Michael

Benutzeravatar
af0815
Lazarusforum e. V.
Beiträge: 6209
Registriert: So 7. Jan 2007, 10:20
OS, Lazarus, FPC: FPC fixes Lazarus fixes per fpcupdeluxe (win,linux,raspi)
CPU-Target: 32Bit (64Bit)
Wohnort: Burgenland
Kontaktdaten:

Re: Programmumstellung von SQLite auf PostgreSQL

Beitrag von af0815 »

SQL ist kompatibel, der Teufel steckt im Detail. Unter den verschiedenen Servern mit ihren Dialekten ist es manchmal nicht ganz einfach.

Die Tabellenerstellung mit den constrains ist unterschiedlich, die Datentypen können abweichen, autoinc Felder sind teilweise sehr unterschiedlich hin gelöst (bis zu eigene Generatoren). Ja es geht, allerdings sollte man die Unterschiede gut kennen und man kommt um Code je System nicht herum. Man sieht es auch wie Persistenzframeworks wie tiOPF und mORMot es machen und wieviel Aufwand dort hineingesteck wird um es eben auf eine neutrale unabhängige Basis zu stellen.
Blöd kann man ruhig sein, nur zu Helfen muss man sich wissen (oder nachsehen in LazInfos/LazSnippets).

Antworten