Andreas hatte mir vor einigen Wochen gesagt, da die Postgresql-Untersttzung wohl nicht wirklich funktioniert. Da ich aber derzeit schon einige Sachen mit dieser Datenbank realisiere, wre es nicht wirklich sinnvoll, jetzt extra fr phpay mysql zu installieren. Daher mein Frage, inwiefern ist phpay mit Postgresql nutzbar? Auf phpay.sf.net wird ja eigentlich davon geschrieben, da MySQL, Postgresql und Interbase untersttzt werden. Wie weit sind nun Theorie und Praxis voneinander entfernt?
Danke.
PS.: nein, ich werde nicht einen Schritt zurck machen, und den Rest auf MySQL umstellen...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Mit Postgre habe ich mich nun noch nicht befat. Wenn die Tabellennamen mit einem Prfix versehen werden (2.02 untersttzt das, siehe db_func.inc.php) sollten die meisten Probleme aus dem Weg gerumt sein.
Wie verhlt sich Postgre bei INSERT-Kommandos, wenn die ID-Spalte eigentlich auto_increment ist, aber trotzdem ein Wert wie '%' oder '' angegeben wird? Funktioniert das?
Ich habe zum Testen mal eine Tabelle test angelegt. Der Aufbau ist nicht wirklich spannend:
CREATE TABLE test (id SERIAL, name VARCHAR);
auto_increment ist in Postgres "SERIAL".
Was soll '%' leisten? Ein INSERT INTO test VALUES ('%', 'Text'); ergibt eine Fehlermeldung (logischerweise)
INSERT INTO test VALUES ('', 'Text'); funktioniert genau einmal, da '' nicht den Default-Wert ergibt, sondern einen leeren String, der von atoi() in 0 bersetzt wird.
Abhilfe schaffen kann man mit einem der beiden INSERT Statements:
INSERT INTO test (name) VALUES ('der Text'); durch das Weglassen des id-Attributs beim INSERT wird der default-Wert eingetragen, also der Zhler erhht.
INSERT INTO test VALUES (nextval('test_id_seq'),'nochmal Text'); macht manuell genau das, was im Hintergrund beim Eintragen des default wertes passiert, und zwar den nextval(...)-Aufruf.
Zu dem oben genannten Artikel: DISTINCT auf Attribute vom Typ TEXT ist kein Poblem, LIMIT ebenfalls nicht. (sowohl LIMIT count, als auch LIMIT ALL)
Gruss.
Christian
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Durch die Prfixe wird erreicht, das Postgre sich nicht an Tabellennamen wie 'user' strt.
Eine eigene Install-Datei fr Postgre mte wahrscheinlich sowieso her. Oder funktionieren die anderen Definitionen alle (decimal(20,4) z.B.?).
Das '%' ist ein Wildcard. MySQL benutzt dann sein auto_increment :-)
Es ist reine Faulheit, da ich nicht die Spaltenliste benutze. Der Aufwand dafr ist geistig nicht sehr anspruchsvoll. Es ist eher ein raussuchen der Spaltennamen, erstellen der Spaltenliste und ndern des Queries.
MySQL kann auch mit
INSERT INTO test (name) VALUES ('Text') umgehen.
Das LIMIT und DISTINCT so wie bei MySQL funktionieren ist ja schon mal was und erspart einiges an Problemen.
Wie verhlt sich Postgre, wenn ich eine Integer-Spalte mit einem String befrage:
SELECT * FROM test WHERE id='1'
Es gibt nmlich einige Stellen, an denen da so formuliert ist, damit es keinen Fehler gibt, falls eine Variable mal keinen Wert hat.
SELECT * FROM test WHERE id='$itemgr'
Gru,
Andreas.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Zu den Prefixen: stimmt. das davon wute ich bis eben nichts.
das mit dem '%' ist ein wenig irrefhrend, weil es ja eigentlich ein wildcard ist.
Die komplette Spaltenliste mu auch nicht angegeben werden, wie aus meinen Beispielen hervorgeht. Man mu beim INSERT INTO lediglich die Spalten angeben, in die man Werte eintragen mchte, alle anderen werden mit dem DEFAULT Wert belegt. Bei einer Spalte vom Typ SERIAL sorgt dann die dahinter liegende Sequence dafr da automatisch der nchste Wert genommen wird. In Fllen, wo man diese DEFAULT Werte in den Spalten haben will _muss_ man ja sogar diese Spalten beim INSERT INTO auslassen, weil ja '' nicht gleich dem DEFAULT ist.
In dem Moment wo Du einen String versuchst in eine Int Spalte zu schreiben oder daraus zu lesen, wird der String mittels atoi() in ein Int umgewandelt.
ein id=5 ist das gleiche wie ein id='5' oder ein id='005' usw.
Was Postgres allerdings macht, sind wirkliche Datentypenverletzungen zu ahnden. Beispielsweise hab ich bei MySQL mal festgestellt, dass es mich nicht daran hindert in eine Int Spalte einen String eintragen zu lassen, der keine Zahl ist. z.B. 'Test' ... es gibt keine Warnung und keine Fehlermeldung, sondern trgt einfach den default wert stattdessen ein. Solche Fehler lt Postgres nicht zu, sondern man bekommt eine Fehlermeldung, wie es auch richtig ist. Sonst braucht man keine Datentypen festlegen, wenn die Datenbank sich nicht meldet, wenn man sie verletzt, dann knnte man jede Spalte als VARCHAR definieren.
Gruss.
Christian
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Freilich mu nicht die komplette Spaltenliste geschribene werden, aber auch die bentigten Spalten(namen) mssen rausgesucht und hingeschrieben werden. Gerade im admin-Bereich sind das einige.
Wenn Postgre, Strings selbst in Integerwerte umwandelt, ist das ja prima. Das erspart einen haufen Arbeit.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Zu Datentypen:
Solange sie SQL92 konform sind, gibt es keine Probleme (SQL99 sollte auch gehen, mte ich jetzt aber in der Doku nachlesen). Probleme gibt es nur bei Erweiterungen, die ber den SQL-Standard hinausgehen, und dann von jedem Hersteller anders implementiert werden. (wie z.B. auto_increment vs. serial)
Hatte nicht schonmal jemand das Script angepasst, was die Datenbank bzw. die Tabellen anlegt? Wenn nicht, schau ich da mal drber.
Gruss
Christian
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ich habe mir mal die create_db.inc.php angeschaut und einige Hinweise/Fragen zusammengestellt.
- ich konnte nichts von einem Prefix in create_db.inc.php erkennen.
- DROP TABLE IF EXISTS nicht implementiert
- unsigned nicht untersttzt
- int(8) ... auto_increment durch SERIAL ersetzen. SERIAL8 ist 8Byte Integerzhler. Der Zhler wird unabhngig vom Typ in der Tabelle immer als int8 angelegt.
- bei PostgreSQL < 7.3.x ist darauf zu Achten, da Indizes und Zhler nicht automatisch gelscht werden, wenn die damit verknpfte Tabelle gelscht wird. ab Postgres 7.3 geht das mittels DROP TABLE tabelle CASCADE;
- int(8), int(11): ersetzen durch int oder numeric(8) bzw. decimal(8), oder int8 wenn Anzahl der Bytes gemeint ist. fr int(11) analog.
- was tut KEY ID (ID), was nicht PRIMARY KEY (ID) schon tun wrde?? (ein Index wird in Postgres da schon angelegt)
- wird KEY kdnr_2 (kdnr) verwendet, um einen Index fr kdnr zu erstellen, und um sicherzustellen, da keine kdnr doppelt vorkommt? (in Tabelle user). Wenn, dann kann das einfach durch ein UNIQUE Constraint erreicht werden, waas automatisch einen Index anlegt.
- warum massenweise PRIMARY Keys, aber keine Foreign Keys? (also Referentielle Integriett)
- was ist tinyint(1)? sowas wie boolean?? oder sowas wie numeric(1)?
- fr IP-Adressen gibt es einen Datentyp (inet)
- was tut FULLTEXT KEY name (name), was ein normaler index nicht tut? (ausser SELECT name FROM characteristicinfo WHERE name LIKE '%dings' zu beschleunigen, was ein normaler Index nicht kann)
- keine Tabellen-/Spaltennamen in ' setzen! (z.B. CREATE TABLE 'it_itgr' (...);) bringt Fehlermeldung.
- warum werden Datumsangaben als VARCHAR(14) gespeichert?? Genauer: Warum VARCHAR, warum nicht als DATE? Wie kommt man auf 14? 2003-02-22 ergibt 10??
- was sollen die backticks (`) beim "INSERT INTO `it_itgr` ..." ?
Gruss.
Christian
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- Hatte ich nicht geschrieben, da die db_func.inc.php Prfixe untersttzt? Und da man fr Postgre eine eigene create_db braucht? Knnte man da vor jeden Tabellennamen noch ein ##prefix## setzen und mit preg_replace() ersetzen?
- unsigned kann einfach wegfallen, auch gut.
- normales INT gengt. Das funktioniert wenigstens auch in anderen DBs
- vergi die Keys. Da kommen noch einige dazu, die von Dir genannten sind da irgendwie reingerutscht.
- Weil MySQL in 3.x keine ForeinKeys macht.
- Ich benutze jedenfalls TINYINT(1) wie BOOLEAN.
- INET gibt es aber nur in Postgre (auch nicht in Oracle oder MS-SQL)
- FULLTEXT - Du sagst es.
- Die zwei Backticks werden sich entfernen lassen; siehe oben.
- Hast Du Dir Operationen, die auf diese Spalten zugreifen mal angesehen? Ich speichere da kein Datum, sondern einen Timestamp. Ich wei auch dafr gibt es einen Datentyp, der allerdings mit Nullen aufgefllt wird, was mir nicht pat. Das wre ein typischer Fall, ob atoi() die Umwandlung in die Reihe kriegt.
Wenn Du mir eine Emailadresse zukommen lt, kann ich Dir die nderungen von sf.readj mal zukommen lassen; er hat sich damit schon mal befat; siehe dieses Forum ;-)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hallo,
Andreas hatte mir vor einigen Wochen gesagt, da die Postgresql-Untersttzung wohl nicht wirklich funktioniert. Da ich aber derzeit schon einige Sachen mit dieser Datenbank realisiere, wre es nicht wirklich sinnvoll, jetzt extra fr phpay mysql zu installieren. Daher mein Frage, inwiefern ist phpay mit Postgresql nutzbar? Auf phpay.sf.net wird ja eigentlich davon geschrieben, da MySQL, Postgresql und Interbase untersttzt werden. Wie weit sind nun Theorie und Praxis voneinander entfernt?
Danke.
PS.: nein, ich werde nicht einen Schritt zurck machen, und den Rest auf MySQL umstellen...
Mit Postgre habe ich mich nun noch nicht befat. Wenn die Tabellennamen mit einem Prfix versehen werden (2.02 untersttzt das, siehe db_func.inc.php) sollten die meisten Probleme aus dem Weg gerumt sein.
Wie verhlt sich Postgre bei INSERT-Kommandos, wenn die ID-Spalte eigentlich auto_increment ist, aber trotzdem ein Wert wie '%' oder '' angegeben wird? Funktioniert das?
Siehe auch: http://sourceforge.net/forum/forum.php?thread_id=817784&forum_id=121974
Gru,
Andreas.
Hi Andreas,
wieso Prefixe? was wird dadurch erreicht?
Ich habe zum Testen mal eine Tabelle test angelegt. Der Aufbau ist nicht wirklich spannend:
CREATE TABLE test (id SERIAL, name VARCHAR);
auto_increment ist in Postgres "SERIAL".
Was soll '%' leisten? Ein INSERT INTO test VALUES ('%', 'Text'); ergibt eine Fehlermeldung (logischerweise)
INSERT INTO test VALUES ('', 'Text'); funktioniert genau einmal, da '' nicht den Default-Wert ergibt, sondern einen leeren String, der von atoi() in 0 bersetzt wird.
Abhilfe schaffen kann man mit einem der beiden INSERT Statements:
INSERT INTO test (name) VALUES ('der Text'); durch das Weglassen des id-Attributs beim INSERT wird der default-Wert eingetragen, also der Zhler erhht.
INSERT INTO test VALUES (nextval('test_id_seq'),'nochmal Text'); macht manuell genau das, was im Hintergrund beim Eintragen des default wertes passiert, und zwar den nextval(...)-Aufruf.
Zu dem oben genannten Artikel: DISTINCT auf Attribute vom Typ TEXT ist kein Poblem, LIMIT ebenfalls nicht. (sowohl LIMIT count, als auch LIMIT ALL)
Gruss.
Christian
Durch die Prfixe wird erreicht, das Postgre sich nicht an Tabellennamen wie 'user' strt.
Eine eigene Install-Datei fr Postgre mte wahrscheinlich sowieso her. Oder funktionieren die anderen Definitionen alle (decimal(20,4) z.B.?).
Das '%' ist ein Wildcard. MySQL benutzt dann sein auto_increment :-)
Es ist reine Faulheit, da ich nicht die Spaltenliste benutze. Der Aufwand dafr ist geistig nicht sehr anspruchsvoll. Es ist eher ein raussuchen der Spaltennamen, erstellen der Spaltenliste und ndern des Queries.
MySQL kann auch mit
INSERT INTO test (name) VALUES ('Text') umgehen.
Das LIMIT und DISTINCT so wie bei MySQL funktionieren ist ja schon mal was und erspart einiges an Problemen.
Wie verhlt sich Postgre, wenn ich eine Integer-Spalte mit einem String befrage:
SELECT * FROM test WHERE id='1'
Es gibt nmlich einige Stellen, an denen da so formuliert ist, damit es keinen Fehler gibt, falls eine Variable mal keinen Wert hat.
SELECT * FROM test WHERE id='$itemgr'
Gru,
Andreas.
Zu den Prefixen: stimmt. das davon wute ich bis eben nichts.
das mit dem '%' ist ein wenig irrefhrend, weil es ja eigentlich ein wildcard ist.
Die komplette Spaltenliste mu auch nicht angegeben werden, wie aus meinen Beispielen hervorgeht. Man mu beim INSERT INTO lediglich die Spalten angeben, in die man Werte eintragen mchte, alle anderen werden mit dem DEFAULT Wert belegt. Bei einer Spalte vom Typ SERIAL sorgt dann die dahinter liegende Sequence dafr da automatisch der nchste Wert genommen wird. In Fllen, wo man diese DEFAULT Werte in den Spalten haben will _muss_ man ja sogar diese Spalten beim INSERT INTO auslassen, weil ja '' nicht gleich dem DEFAULT ist.
In dem Moment wo Du einen String versuchst in eine Int Spalte zu schreiben oder daraus zu lesen, wird der String mittels atoi() in ein Int umgewandelt.
ein id=5 ist das gleiche wie ein id='5' oder ein id='005' usw.
Was Postgres allerdings macht, sind wirkliche Datentypenverletzungen zu ahnden. Beispielsweise hab ich bei MySQL mal festgestellt, dass es mich nicht daran hindert in eine Int Spalte einen String eintragen zu lassen, der keine Zahl ist. z.B. 'Test' ... es gibt keine Warnung und keine Fehlermeldung, sondern trgt einfach den default wert stattdessen ein. Solche Fehler lt Postgres nicht zu, sondern man bekommt eine Fehlermeldung, wie es auch richtig ist. Sonst braucht man keine Datentypen festlegen, wenn die Datenbank sich nicht meldet, wenn man sie verletzt, dann knnte man jede Spalte als VARCHAR definieren.
Gruss.
Christian
Freilich mu nicht die komplette Spaltenliste geschribene werden, aber auch die bentigten Spalten(namen) mssen rausgesucht und hingeschrieben werden. Gerade im admin-Bereich sind das einige.
Wenn Postgre, Strings selbst in Integerwerte umwandelt, ist das ja prima. Das erspart einen haufen Arbeit.
Zu Datentypen:
Solange sie SQL92 konform sind, gibt es keine Probleme (SQL99 sollte auch gehen, mte ich jetzt aber in der Doku nachlesen). Probleme gibt es nur bei Erweiterungen, die ber den SQL-Standard hinausgehen, und dann von jedem Hersteller anders implementiert werden. (wie z.B. auto_increment vs. serial)
Hatte nicht schonmal jemand das Script angepasst, was die Datenbank bzw. die Tabellen anlegt? Wenn nicht, schau ich da mal drber.
Gruss
Christian
Ich habe mir mal die create_db.inc.php angeschaut und einige Hinweise/Fragen zusammengestellt.
- ich konnte nichts von einem Prefix in create_db.inc.php erkennen.
- DROP TABLE IF EXISTS nicht implementiert
- unsigned nicht untersttzt
- int(8) ... auto_increment durch SERIAL ersetzen. SERIAL8 ist 8Byte Integerzhler. Der Zhler wird unabhngig vom Typ in der Tabelle immer als int8 angelegt.
- bei PostgreSQL < 7.3.x ist darauf zu Achten, da Indizes und Zhler nicht automatisch gelscht werden, wenn die damit verknpfte Tabelle gelscht wird. ab Postgres 7.3 geht das mittels DROP TABLE tabelle CASCADE;
- int(8), int(11): ersetzen durch int oder numeric(8) bzw. decimal(8), oder int8 wenn Anzahl der Bytes gemeint ist. fr int(11) analog.
- was tut KEY ID (ID), was nicht PRIMARY KEY (ID) schon tun wrde?? (ein Index wird in Postgres da schon angelegt)
- wird KEY kdnr_2 (kdnr) verwendet, um einen Index fr kdnr zu erstellen, und um sicherzustellen, da keine kdnr doppelt vorkommt? (in Tabelle user). Wenn, dann kann das einfach durch ein UNIQUE Constraint erreicht werden, waas automatisch einen Index anlegt.
- warum massenweise PRIMARY Keys, aber keine Foreign Keys? (also Referentielle Integriett)
- was ist tinyint(1)? sowas wie boolean?? oder sowas wie numeric(1)?
- fr IP-Adressen gibt es einen Datentyp (inet)
- was tut FULLTEXT KEY name (name), was ein normaler index nicht tut? (ausser SELECT name FROM characteristicinfo WHERE name LIKE '%dings' zu beschleunigen, was ein normaler Index nicht kann)
- keine Tabellen-/Spaltennamen in ' setzen! (z.B. CREATE TABLE 'it_itgr' (...);) bringt Fehlermeldung.
- warum werden Datumsangaben als VARCHAR(14) gespeichert?? Genauer: Warum VARCHAR, warum nicht als DATE? Wie kommt man auf 14? 2003-02-22 ergibt 10??
- was sollen die backticks (`) beim "INSERT INTO `it_itgr` ..." ?
Gruss.
Christian
- Hatte ich nicht geschrieben, da die db_func.inc.php Prfixe untersttzt? Und da man fr Postgre eine eigene create_db braucht? Knnte man da vor jeden Tabellennamen noch ein ##prefix## setzen und mit preg_replace() ersetzen?
- unsigned kann einfach wegfallen, auch gut.
- normales INT gengt. Das funktioniert wenigstens auch in anderen DBs
- vergi die Keys. Da kommen noch einige dazu, die von Dir genannten sind da irgendwie reingerutscht.
- Weil MySQL in 3.x keine ForeinKeys macht.
- Ich benutze jedenfalls TINYINT(1) wie BOOLEAN.
- INET gibt es aber nur in Postgre (auch nicht in Oracle oder MS-SQL)
- FULLTEXT - Du sagst es.
- Die zwei Backticks werden sich entfernen lassen; siehe oben.
- Hast Du Dir Operationen, die auf diese Spalten zugreifen mal angesehen? Ich speichere da kein Datum, sondern einen Timestamp. Ich wei auch dafr gibt es einen Datentyp, der allerdings mit Nullen aufgefllt wird, was mir nicht pat. Das wre ein typischer Fall, ob atoi() die Umwandlung in die Reihe kriegt.
Wenn Du mir eine Emailadresse zukommen lt, kann ich Dir die nderungen von sf.readj mal zukommen lassen; er hat sich damit schon mal befat; siehe dieses Forum ;-)