![]() |
Datenbank: MySQL • Version: 5.0.51a • Zugriff über: PHP Wrapper-Klasse mit mysql_connect() ...
Allgemeiner SQL-Syntax für Multi-DBMS Projekt
Hallo liebe DP-ler,
ich bin gerade dabei mein CMS von Grund auf neu zu Programmieren und möchte jetzt die SQL Abfragen so allgemein wie möglich halten, damit ich durch austauschen der DB-Klasse andere Datenbank-Syteme wie PostgreSQL oder MSSQL verwenden kann. Beispiel MySQL-Abfrage
SQL-Code:
Wie könnte ich diese Abfrage so allgemein wie möglich halten? In MySQL sind ja ` die Seperatoren für Spaltennamen, in MSSQL wiederung [ und ] und in PostgreSQL glaube ich ".
SELECT `user_id` FROM `user` WHERE `user_id` < 42 ORDER BY `order`;
Gibt es da nichts einheitliches? Ich möchte ungern die Querys doppelt im Sourcecode haben. Mfg Klaus |
Re: Allgemeiner SQL-Syntax für Multi-DBMS Projekt
Für PHP gibt es schon einige Wrapper: MDB2, PDO, ADODB, ...
|
Re: Allgemeiner SQL-Syntax für Multi-DBMS Projekt
Bezeichner in Quotes sind doch nur nötig, wenn du ein keyword nutzt, oder der Name gegen die Regeln von Bezeichnern verstößt.
IOW: Du musst gar nichts in Single/Doublequotes, oder MSSQLs komische Klammern. Ich habe absolut gar keinen Schimmer, warum mySQL-Opfer ständig diese Quotes setzen... Edit2: Oh sorry, du musst ja PHP nutzen... |
Re: Allgemeiner SQL-Syntax für Multi-DBMS Projekt
Klammern will ich setzten wg. Keywords. (Habe auch gar keinen Einfluss auf die Feldnamen)
Die Wrapper von PHP sind dann quasi ne Schnittstelle, die ich mit allgemeiner Syntax ansprechen kann? |
Re: Allgemeiner SQL-Syntax für Multi-DBMS Projekt
Jein. Im gewissen Umfang
|
Re: Allgemeiner SQL-Syntax für Multi-DBMS Projekt
Zitat:
Der User kann anscheinend über dein System eigene Tabellen kreieren? Dann sind deine SQLs doch eh dynamisch (du hast ja alle Metadaten bei der Hand) und wenn du die SQLs zusammenbaust, nutzt du halt die entsprechenden Quotes. Ich habe keinen Plan von den Zugriffslibs von PHP (glücklicherweise ;-) ), kann dir also nicht sagen, ob adodb alleine die Quotes übersetzt. |
Re: Allgemeiner SQL-Syntax für Multi-DBMS Projekt
Zitat:
Nein, im Ernst: Schreibe Dir lieber eine Klassenbibliothek, welche Dir die Objekte so liefert, wie Du sie weiterverarbeiten kannst. Dann ersetzt Du die Klassenbibliothek für die einzelnen DBMS (zB um bei der Delphi-Syntax zu bleiben: TUser - abstract, TMySQLUser, TMSSQLUser, TPGUser usw). Grund? Es gibt nichts wirklich einheitliches, die SQL Syntax unterscheidet sich, wenn auch nur minimal. Und denke mal über SQL Injection nach: Du musst Parameter verwenden, damit Dir das nicht passiert und das Parameter-Handling von MySQL ist mehr als umständlich. |
Re: Allgemeiner SQL-Syntax für Multi-DBMS Projekt
Zitat:
|
Re: Allgemeiner SQL-Syntax für Multi-DBMS Projekt
Zitat:
|
Re: Allgemeiner SQL-Syntax für Multi-DBMS Projekt
Oracle (9i) kann's auch nicht. Da verwendet man am besten "FROM DUAL"...
Grüße Mikhal |
Re: Allgemeiner SQL-Syntax für Multi-DBMS Projekt
Zitat:
|
Re: Allgemeiner SQL-Syntax für Multi-DBMS Projekt
OK danke, ich sehe schon da gibt es keine Lösung die für alle Systeme gilt.
Dann definiere ich halt in der DB Klasse des Trennzeichen als Attribut und klatsch das halt immer rein. Danke. |
Re: Allgemeiner SQL-Syntax für Multi-DBMS Projekt
Zitat:
|
Re: Allgemeiner SQL-Syntax für Multi-DBMS Projekt
Zitat:
btw: die klammern würd ich gleich von anfang an vergessen. |
Re: Allgemeiner SQL-Syntax für Multi-DBMS Projekt
Zitat:
SQL-Code:
Also liefert "Feld42" den Inhalt des Feldes, während 'Feld42' als Stringkonstante in jedem Datensatz erscheint.
SELECT "Feld42", 'Feld42' FROM ....
Ich würde alle Feld- und Tabellennamen so wählen, dass die Anführungszeichen nicht nötig sind. Deine Datenbanken sollen vielleicht auch mal mit externen Tools abgefragt werden, die keine Anführungszeichen verwenden und dann Probleme bekommen. 1.) max. 32 Zeichen 2.) nur Buchstaben, Ziffern und Unterstrich erlaubt 3.) niemals mit Ziffer beginnen 4.) keine reservierten Wörter verwenden (select, count, create, table, alter, user, .. ~ 400 Stück) |
Alle Zeitangaben in WEZ +1. Es ist jetzt 11:21 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz